Skip to content
This repository has been archived by the owner on Jul 1, 2022. It is now read-only.

Change Copyright to rightType: Copyright #29

Open
wants to merge 5 commits into
base: master
Choose a base branch
from
Open

Change Copyright to rightType: Copyright #29

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
adacf3a
Remove copyright from json-ld schema
TimDaub Nov 19, 2018
e29e624
Add rightType
TimDaub Nov 20, 2018
7e59a7d
Change Copyright to rightType:Copyright
TimDaub Nov 20, 2018
8167a21
Copyright => Right
TimDaub Nov 20, 2018
5343372
Make spec clearer IRT Copyright semantics
TimDaub Dec 10, 2018
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions .gitignore
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1 @@
.DS_Store
86 changes: 44 additions & 42 deletions README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1386,11 +1386,11 @@ Transforming the RRM `Right` entity poses some challenges. According to the RRM


For the purposes of storing `Right`s on decentralized ledgers, we ignore the requirements of the
`lcc:RightSet` and model `Right`s as atomically transferrable containers of licensing information.
To make a distinction between derived licensing information and a full copyright, we separately
[explore the semantics of copyright later](#copyright-semantics). To the best of our knowledge,
there are no existing RDF schemata for creating such containers, so we propose the following to
satisfy the consolidated requirements of:
`lcc:RightSet` and model `Right`s as atomically transferrable containers of licensing and copyright
information. To make a distinction between derived licensing information and a full copyright, we
separately [explore the semantics of copyright later](#copyright-semantics). To the best of our
knowledge, there are no existing RDF schemata for creating such containers, so we propose the
following to satisfy the consolidated requirements of:

- [LCC: Rights Reference Model](http://doi.org/10.1000/284);
- [W3C: Open Digital Rights Language](https://www.w3.org/TR/odrl/); and
Expand All @@ -1403,6 +1403,7 @@ satisfy the consolidated requirements of:
"@context": "http://coalaip.schema/",
"@type": "Right",
"@id": "<URI pointing to this object>",
"rightType": "License",
"usages": "all|copy|play|stream|...",
"territory": "<URI pointing to a Place>",
"context": "inflight|inpublic|commercialuse...",
Expand All @@ -1417,7 +1418,7 @@ satisfy the consolidated requirements of:
"@type": "Date",
"@value": "2017-01-01"
},
"source": "<URI pointing to a Copyright>",
"rightsOf": "<URI pointing to a Right of rightType: Copyright>",
"license": "<URI pointing to a license on an immutable ledger>"
}
```
Expand All @@ -1434,6 +1435,7 @@ this in mind, the implementation in IPLD (on IPFS) is favoured:
{
"@context": { "/": "<hash pointing to coalaip.schema's context>" },
"@type": "Right",
"rightType": "License",
"usages": "all|copy|play|stream|...",
"territory": { "/": "<hash pointing to a Place>" },
"context": "inflight|inpublic|commercialuse...",
Expand All @@ -1448,35 +1450,34 @@ this in mind, the implementation in IPLD (on IPFS) is favoured:
"@type": "Date",
"@value": "2017-01-01"
},
"source": { "/": "<hash pointing to a Copyright>" },
"rightsOf": { "/": "<hash pointing to a Right of rightType: Copyright>" },
"license": { "/": "<hash pointing to a license>" }
}
```

In our transformation, it is important to highlight that every `Right` must include a `source` (or
equivalent) property that links it to an enabling `Copyright` or parent `Right`. With use on an
immutable ledger in mind, the `source` property implements support for `lcc:SourceRight`s–albeit in
a "backwards" relation in comparison to the RRM's definition–a `Right` containing a `source`
In our transformation, it is important to highlight that every `Right` shall include a `rightsOf` (or
equivalent) property that links it to an enabling `Right` of `rightType: Copyright`. With use on an
immutable ledger in mind, the `rightsOf` property implements support for `lcc:SourceRight`s–albeit in
a "backwards" relation in comparison to the RRM's definition–a `Right` containing a `rightsOf`
property is the derivation while the pointed-to entity is the `lcc:SourceRight`.

#### Copyright Semantics

Although RRM `Right`s are capable of representing both full copyrights as well as derived licenses
to `Creation`s, we split these two concepts into different entities to better represent them within
distributed ledgers. We base the structure of the `Copyright` entity on the `Right` entity's, but as
only a subset of the `Right`'s properties pertain to `Copyright`s (e.g. "territory", "validFrom",
etc.), we do not require implementations to subtype `Copyright`s from `Right`s. However,
semantically, and for the purposes of discussion, we treat `Copyright`s as a subtype of `Right`s.
Similarly to `Right`s, we propose that `Copyright`s be stored on decentralized ledgers for
maintaining ownership and provenance.
RRM `Rights` are capable of representing both full Copyright as well as derived licenses. As Copyright,
we define the original group of rights assigned to a creator (or creators) by law. In the last
paragraph, we introduced the property `rightType`. It can be used to describe either a license with
`rightType: License` or a Copyright with `rightType: Copyright`. Similarly to `Right`s, we propose
that Rights of `rightType: Copyright`s be stored on decentralized ledgers for maintaining ownership and
provenance.

We propose:

```javascript
// In JSON-LD
{
"@context": "http://coalaip.schema/",
"@type": "Copyright",
"@type": "Right",
"rightType": "Copyright",
"rightsOf": "<URI pointing to a Creation (usually a Manifestation)>",
"territory": "<URI pointing to a Place>",
"validFrom": {
Expand All @@ -1492,7 +1493,8 @@ We propose:
// In IPLD
{
"@context": { "/": "<hash pointing to coalaip.schema's context>" },
"@type": "Copyright",
"@type": "Right",
"rightType": "Copyright",
"rightsOf": { "/": "<hash pointing to a Creation (usually a Manifestation)>" },
"territory": { "/": "<hash pointing to a Place>" },
"validFrom": {
Expand All @@ -1506,23 +1508,23 @@ We propose:
}
```

For implementations, we recommend that `Copyright`s be automatically registered with their
For implementations, we recommend that `rightType: Copyright`s be automatically registered with their
`Manifestation`s so as to immediately state the `Manifestation`'s copyright holder and allow other
`Right`s to be derived from the `Copyright`. Given that multiple `Copyright`s may be needed, e.g.
for multiple regions, there is no limit to the number of `Copyright`s that can be attached to a
given `Manifestation` (for potential conflicts, see [`Assertion`s](#the-rrm-assertion-entity) and
[`RightsConflict`s](#the-rrm-rightsconflict-entity).
`Right`s to be derived from the `rightType: Copyright`. Given that multiple `rightType: Copyright`s
may be needed, e.g. for multiple regions, there is no limit to the number of `rightType: Copyright`s
that can be attached to a given `Manifestation` (for potential conflicts, see [`Assertion`s](#the-rrm-assertion-entity)
and [`RightsConflict`s](#the-rrm-rightsconflict-entity).

#### The Notion of Ownership

Given that `Right`s and `Copyright`s are designed to be stored on decentralized ledgers, we propose
to link these entities with their related rightsholding `Party`s by cryptographic ownership.
Assuming the ledger natively supports cryptographic ownership of assets, this results in only the
owners of a `Right` or `Copyright` on the ledger to be maintained as the rightsholders. Moreover,
this means that only these owners are able to repurpose the `Right` by, for example, initiating a
[`RightsAssignment`](#the-rrm-rightsassignment) to a another `Party`. Ledgers should be chosen so
that all forms (e.g. transfers, loans, consignments, etc.) of these transactions (i.e. RRM
`RightsAssignment`s) can be stored in an ordered fashion to maintain each right's chain of
Given that `Right`s and Rights of `rightType: Copyright` are designed to be stored on decentralized
ledgers, we propose to link these entities with their related rightsholding `Party`s by cryptographic
ownership. Assuming the ledger natively supports cryptographic ownership of assets, this results in
only the owners of a `Right` or `rightType: Copyright` on the ledger to be maintained as the rightsholders.
Moreover, this means that only these owners are able to repurpose the `Right` by, for example,
initiating a [`RightsAssignment`](#the-rrm-rightsassignment) to a another `Party`. Ledgers should
be chosen so that all forms (e.g. transfers, loans, consignments, etc.) of these transactions
(i.e. RRM `RightsAssignment`s) can be stored in an ordered fashion to maintain each right's chain of
provenance.

With RRM `Right`s modelled in such a fashion, any digital creator that wants to register and
Expand All @@ -1532,16 +1534,16 @@ distribute the `Right`s of a `Manifestation` to interested `Party`s must:
1. Register their `Creation` as a `Work` on a global registry and link it to their `Party`
identifier;
1. Register `Manifestation`s to the `Work` on a global registry;
1. Register a `Copyright` for the `Manifestation` on a global registry;
1. Derive any number of `Right`s tailored to interested `Party`s from the `Copyright` and register
them on a global registry; and
1. Register a `Right` of `rightType: Copyright` for the `Manifestation` on a global registry;
1. Derive any number of `Right`s tailored to interested `Party`s from the `rightType: Copyright`
and register them on a global registry; and
1. Register `RightAssignment`s to assign these `Right`s to interested `Party`s.


The above steps highlight how a `Right` is not only limited to registration; with the use of a
ledger, `Right`s also contain properties of ownership and can be transferred from one `Party` to
another via `RightsAssignment`s. The owner of a `Right` or `Copyright` on the ledger is maintained
to be the rightsholder.
another via `RightsAssignment`s. The owner of a `Right` or `Right` of `rightType: Copyright` on
the ledger is maintained to be the rightsholder.

However, there are a few edge cases to consider when licensing information is stored this way:

Expand All @@ -1556,9 +1558,9 @@ However, there are a few edge cases to consider when licensing information is st

It is important to note that with these ownership semantics for copyrights and licenses, the
ownership of a `Work` or `Manifestation` is essentially meaningless: these entities simply contain
information about a creative work and are used as pointers for `Copyright`s and `Right`s. As such,
storing `Work`s and `Manifestation`s in ledgers is unnecessary and an immutable data store, e.g.
IPFS, can be used instead if cross-protocol links are supported (i.e. multiaddr).
information about a creative work and are used as pointers for `Right`s. As such, storing `Work`s
and `Manifestation`s in ledgers is unnecessary and an immutable data store, e.g. IPFS, can be used
instead if cross-protocol links are supported (i.e. multiaddr).


### The RRM `RightsAssignment` Entity
Expand Down
54 changes: 9 additions & 45 deletions schema/README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -502,16 +502,6 @@ As no existing schema.org vocabulary fits the RRM's notion of a `Right` or [COAL
`Copyright`](#link-me), we define our own classes with the following vocabulary:

```javascript
// Copyright Class
{
"@id": "<coalaip placeholder>/Copyright",
"@type": "rdfs:Class",
"rdfs:subClassOf": {
"@id": "schema:Intangible"
},
...
}

// Right Class
{
"@id": "<coalaip placeholder>/Right",
Expand Down Expand Up @@ -582,7 +572,7 @@ As no existing schema.org vocabulary fits the RRM's notion of a `Right` or [COAL
"@id": "<coalaip placeholder>/rightsOf",
"@type": "rdf:Property",
"schema:domainIncludes": {
"@id": "coala:Copyright"
"@id": "coala:Right"
},
"schema:rangeIncludes": {
"@id": "schema:CreativeWork"
Expand All @@ -593,34 +583,13 @@ As no existing schema.org vocabulary fits the RRM's notion of a `Right` or [COAL
...
}

// Source Property
{
"@id": "<coalaip placeholder>/source",
"@type": "rdf:Property",
"schema:domainIncludes": {
"@id": "coala:Right"
},
"schema:rangeIncludes": {
"@id": "coala:Copyright"
},
"owl:equivalentProperty": {
"@id": "dc:source"
},
...
}

// Territory Property
{
"@id": "<coalaip placeholder>/territory",
"@type": "rdf:Property",
"schema:domainIncludes": [
{
"@id": "coala:Copyright"
},
{
"schema:domainIncludes": {
"@id": "coala:Right"
}
],
},
"schema:rangeIncludes": {
"@id": "schema:Place"
},
Expand Down Expand Up @@ -648,9 +617,6 @@ As no existing schema.org vocabulary fits the RRM's notion of a `Right` or [COAL
"@id": "<coalaip placeholder>/validFrom",
"@type": "rdf:Property",
"schema:domainIncludes": [
{
"@id": "coala:Copyright"
},
{
"@id": "coala:Right"
},
Expand All @@ -677,9 +643,6 @@ As no existing schema.org vocabulary fits the RRM's notion of a `Right` or [COAL
"@id": "<coalaip placeholder>/validThrough",
"@type": "rdf:Property",
"schema:domainIncludes": [
{
"@id": "coala:Copyright"
},
{
"@id": "coala:Right"
},
Expand Down Expand Up @@ -711,7 +674,7 @@ As no existing schema.org vocabulary fits the RRM's notion of a `Right` or [COAL
registrar of a `Right`
- `schema.org/license` can be used to provide a URL to the legal license document covering a `Right`

An example of a `Copyright` and a derived `Right`:
An example of a `rightType: Copyright` and a derived `Right`:

```javascript
// Note: We assume that the data will be put on an immutable ledger, forcing all links to point "backwards."
Expand All @@ -724,8 +687,9 @@ An example of a `Copyright` and a derived `Right`:
"http://schema.org/",
"<coalaip placeholder>"
],
"@type": "<coalaip placeholder>/Copyright",
"@type": "<coalaip placeholder>/Right",
"@id": "<URI pointing to this object>",
"rightType": "Copyright",
"rightsOf": "<URI pointing to a CreativeWork object (usually should be a Manifestation)>",
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this generally makes good sense to me, although I'm still a little bit confused because in some instances rightsOf is said to point to a CreativeWork and in others it still says that it points to a URI of a Copyright object. Wouldn't Copyright objects no longer exist if that schema is removed from the spec?

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think an example of what what a rightsOf property could point to would help clarify here. For example in the case of Ujo we are issuing Right objects that reference MusicRecording objects. Would rightOf point to the MusicRecording object in JSON format, or a legal document that is hashes and stored on chain? At the moment in our implementation we are not populating this field due to this uncertainty. We are hoping to migrate the data to be inline with the spec though.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Another potentially related question here is how Rights are expected to be referenced from a CreativeWork. In other words, if I have a CreativeWork object, should it contain an array of Right objects? In our case this is how we handle it in order to reference percentageShares on a MusicRecording and then split payments that are made on chain. This seems like a common usecase for these Right objects, but the way we are handling it currently seems potentially out of line with this spec.

Copy link
Contributor Author

@TimDaub TimDaub Dec 10, 2018 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wouldn't Copyright objects no longer exist if that schema is removed from the spec?

In this PR I'm proposing to not completely the concept of Copyright but to make it part of the Right entity by introducing a rightType: Copyright, like proposed in the RRM.

Would rightOf point to the MusicRecording object in JSON format, or a legal document that is hashes and stored on chain?

rightOf would always point to the MusicRecording object in JSON format. We have the property license in Right that points to the legal document.

Another potentially related question here is how Rights are expected to be referenced from a CreativeWork.
In other words, if I have a CreativeWork object, should it contain an array of Right objects?

@vrde and I stumped upon the same issue when we did some work for the OMI: #24 I'm afraid we currently don't have a good answer in the specification for this problem. Additionally, it's specific to the blockchain or DLT you're saving the Right onto. IPFS e.g. is not searchable, so backward pointing links are required. Other solutions might one day be available where searching is possible. Until then, we need a makeshift solution. @alexanderattar would you mind adding this use case somewhere in this repo as an issue?

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Aha..okay yeah that makes sense. I'm happy to open a separate issue for this

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

here we go: #31

"territory": "<URI pointing to a Place object>",
"validFrom": "2016-01-01",
Expand All @@ -740,7 +704,7 @@ An example of a `Copyright` and a derived `Right`:
],
"@type": "<coalaip placeholder>/Right",
"@id": "<URI pointing to this object>",
"source": "<URI pointing to a Copyright object>",
"rightsOf": "<URI pointing to a Copyright object>",
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For example this line

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I hope I made this more clear in 5343372

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes! Okay I understand now. Looks good to me!

"usageType": ["all", "copy", "play"],
"territory": "<URI pointing to a Place object>",
"rightContext": ["inflight", "inpublic", "commercialuse"],
Expand All @@ -759,7 +723,7 @@ An example of a `Copyright` and a derived `Right`:
"http://schema.org/",
"<coalaip placeholder>"
],
"@type": "<coalaip placeholder>/Copyright",
"@type": "<coalaip placeholder>/Right",
"rightsOf": { "/": "<hash pointing to a CreativeWork object (that should be a Manifestation)>" },
"territory": { "/": "<hash pointing to a Place object>" },
"validFrom": "2016-01-01",
Expand All @@ -773,7 +737,7 @@ An example of a `Copyright` and a derived `Right`:
{ "/": "<hash pointing to COALA IP's context>" }
],
"@type": "<coalaip placeholder>/Right",
"source": { "/": "<hash pointing to a Copyright object>" },
"rightsOf": { "/": "<hash pointing to a Copyright object>" },
"usageType": ["all", "copy", "play"],
"territory": { "/": "<hash pointing to a Place object>" },
"rightContext": ["inflight", "inpublic", "commercialuse"],
Expand Down
6 changes: 1 addition & 5 deletions schema/coala_context.json
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -11,7 +11,6 @@

"AbstractWork": "coala:AbstractWork",
"Manifestation": "coala:Manifestation",
"Copyright": "coala:Copyright",
"DigitalFingerprint": "coala:DigitalFingerprint",
"Right": "coala:Right",
"RightsTransferAction": "coala:RightsTransferAction",
Expand All @@ -38,14 +37,11 @@
"numberOfUses": "coala:numberOfUses",
"percentageShares": "coala:percentageShares",
"rightContext": "coala:rightContext",
"rightType": "coala:rightType",
"rightsOf": {
"@id": "coala:rightsOf",
"@type": "@id"
},
"source": {
"@id": "coala:source",
"@type": "@id"
},
"territory": {
"@id": "coala:territory",
"@type": "@id"
Expand Down
Loading