coalaip / specs Goto Github PK

Please see #29 (comment) for context.

The gist is that a type of CreativeWork, for instance a MusicRecording might need to reference the associated rights for various purposes. A realistic example is in the instance of paying for a MusicRecording it is convenient to reference the rights as an array property on the MusicRecording object. This enables the frontend of an application to retrieve JSON data for the object, key into the percentageShares prop and combine the values in the rights array to split the payments.

An idiomatic way of creating this reference is not currently designed in the spec though so application developers might come up with adhoc solutions that fit outside the spec. Additionally, having a rights array on CreativeWork objects does not adhere to the type properties in schema.org. We should have a consistent way of referencing rights via CreativeWorks that is defined within the spec, but also allow for the flexibility for application developers to serialize this in a convenient way

• https://github.com/bigchaindb/pycoalaip
• https://github.com/bigchaindb/pycoalaip-bigchaindb

http://musicontology.com/specification/#term-Release

From #8, and see https://github.com/ipld/specs.

Includes #21

Here is the use case:

https://github.com/COALAIP/omi-mvi-1.0/pull/27/files#diff-7a3547ef9edc199cc8d3c9feab875725R1

Ask @vrde or @TimDaub for more information.

Right now, we have some hand-wavy methods of differentiating between a Work and a Manifestation. This could be simplified if we subtype schema:CreativeWork with something like coala:AbstractWork and enforce that all Works use this type. Works right now are always schema:CreativeWork anyway.

Would require some changes to pycoalaip.

Thoughts @TimDaub?

It might be nice to organize the initial explanatory sections into a few high-level groups to make them more cohesive.

What I'm thinking right now:

1. LCC
2. Semantic Web
3. Immutable Ledgers (IPLD could belong here or in Semantic Web)

Hello @TimDaub and team,

I hope you've been well :)

I am continuing to model some data via coala ip and picking up on development where we left off with js-coalaip. I have read the proposed rational for splitting Copyright and Right into separate entities (https://github.com/COALAIP/specs/blob/master/README.md#copyright-semantics), but the benefit from doing so continues to be unclear to me. The difference seems to be that Rights are designed to be transferable, whereas Copyrights are designed to only be created during the registration of a Manifestation (please correct me if this is wrong). In it's current form there isn't a percentageShares field on the Copyright so an additional Right object would have to be created even for the initial copyright holders and then the source field would have to link back to the Copyright. Given the idea that there could be RightsAssignments to change ownership of the Right object it seems like the Copyright would become invalid after such an assignment.

My suggestion is to conflate these models to eliminate duplication by either adding the "rightsOf": "<URI pointing to a Creation (usually a Manifestation)>", field to the Right type or allowing the source field on the Right to also point to a Creation. Another possibility is adding the percentageShares field to the Copyright type (I am not sure it makes sense to have this on both Copyright and Right, but there should be a way to indicate the initial owners share percentage prior to any subsequent assignment). Interested to get your thoughts / suggestions.

Cheers,

Probably easiest with something like https://github.com/thlorenz/doctoc.

We should at least introduce the concept to give readers some context before suddenly framing the implementation discussion around using one.