From adacf3ae47925123841fef29058463bdb5e750b3 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Tim=20Daubensch=C3=BCtz?= Date: Mon, 19 Nov 2018 14:57:10 +0100 Subject: [PATCH 1/5] Remove copyright from json-ld schema --- schema/coala_context.json | 5 --- schema/vocab/coala.jsonld | 65 ++++++++++----------------------------- 2 files changed, 16 insertions(+), 54 deletions(-) diff --git a/schema/coala_context.json b/schema/coala_context.json index 360b8e7..676b148 100644 --- a/schema/coala_context.json +++ b/schema/coala_context.json @@ -11,7 +11,6 @@ "AbstractWork": "coala:AbstractWork", "Manifestation": "coala:Manifestation", - "Copyright": "coala:Copyright", "DigitalFingerprint": "coala:DigitalFingerprint", "Right": "coala:Right", "RightsTransferAction": "coala:RightsTransferAction", @@ -42,10 +41,6 @@ "@id": "coala:rightsOf", "@type": "@id" }, - "source": { - "@id": "coala:source", - "@type": "@id" - }, "territory": { "@id": "coala:territory", "@type": "@id" diff --git a/schema/vocab/coala.jsonld b/schema/vocab/coala.jsonld index 35060f0..6d77063 100644 --- a/schema/vocab/coala.jsonld +++ b/schema/vocab/coala.jsonld @@ -26,18 +26,6 @@ "rdfs:comment": "A perceivable manifestation of an AbstractWork.", "rdfs:label": "Manifestation" }, - { - "@id": "coala:Copyright", - "@type": "rdfs:Class", - "rdfs:subClassOf": { - "@id": "schema:Intangible" - }, - "owl:equivalentClass": { - "@id": "dc:RightsStatement" - }, - "rdfs:comment": "Describes the full copyright for a Creation.", - "rdfs:label": "Copyright" - }, { "@id": "coala:DigitalFingerprint", "@type": "rdfs:Class", @@ -69,19 +57,24 @@ "rdfs:label": "RightsTransferAction" }, { - "@id": "coala:source", + "@id": "coala:rightsOf", "@type": "rdf:Property", "schema:domainIncludes": { - "@id": "coala:Right" - }, - "schema:rangeIncludes": { - "@id": "schema:Copyright" + "@id": "coala:Manifestation" }, + "schema:rangeIncludes": [ + { + "@id": "schema:CreativeWork" + }, + { + "@id": "coala:Right" + } + ], "owl:equivalentProperty": { - "@id": "dc:source" + "@id": "dc:rights" }, - "rdfs:comment": "The source object upon which another object was derived from. For example, the source Copyright upon which a narrower Right was allowed by.", - "rdfs:label": "source" + "rdfs:comment": "The rightsOf object upon which a Right was derived from. In many cases a Manifestation of another Right", + "rdfs:label": "rightsOf" }, { "@id": "coala:asserter", @@ -231,32 +224,12 @@ "rdfs:comment": "The context in which a Right may be exercised. User defined.", "rdfs:label": "rightContext" }, - { - "@id": "coala:rightsOf", - "@type": "rdf:Property", - "schema:domainIncludes": { - "@id": "coala:Copyright" - }, - "schema:rangeIncludes": { - "@id": "schema:CreativeWork" - }, - "owl:equivalentProperty": { - "@id": "dc:rights" - }, - "rdfs:comment": "The Creation upon which a Copyright is concerned with.", - "rdfs:label": "rightsOf" - }, { "@id": "coala:territory", "@type": "rdf:Property", - "schema:domainIncludes": [ - { - "@id": "coala:Copyright" - }, - { - "@id": "coala:Right" - } - ], + "schema:domainIncludes":{ + "@id": "coala:Right" + }, "schema:rangeIncludes": { "@id": "schema:Place" }, @@ -302,9 +275,6 @@ "@id": "coala:validFrom", "@type": "rdf:Property", "schema:domainIncludes": [ - { - "@id": "coala:Copyright" - }, { "@id": "coala:Right" }, @@ -330,9 +300,6 @@ "@id": "coala:validThrough", "@type": "rdf:Property", "schema:domainIncludes": [ - { - "@id": "coala:Copyright" - }, { "@id": "coala:Right" }, From e29e624aa91966988c5b68dd60f8a57f44dfcd24 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Tim=20Daubensch=C3=BCtz?= Date: Tue, 20 Nov 2018 09:58:37 +0100 Subject: [PATCH 2/5] Add rightType --- .gitignore | 1 + schema/coala_context.json | 1 + schema/vocab/coala.jsonld | 12 ++++++++++++ 3 files changed, 14 insertions(+) create mode 100644 .gitignore diff --git a/.gitignore b/.gitignore new file mode 100644 index 0000000..e43b0f9 --- /dev/null +++ b/.gitignore @@ -0,0 +1 @@ +.DS_Store diff --git a/schema/coala_context.json b/schema/coala_context.json index 676b148..b9aeb01 100644 --- a/schema/coala_context.json +++ b/schema/coala_context.json @@ -37,6 +37,7 @@ "numberOfUses": "coala:numberOfUses", "percentageShares": "coala:percentageShares", "rightContext": "coala:rightContext", + "rightType": "coala:rightType", "rightsOf": { "@id": "coala:rightsOf", "@type": "@id" diff --git a/schema/vocab/coala.jsonld b/schema/vocab/coala.jsonld index 6d77063..e00cedb 100644 --- a/schema/vocab/coala.jsonld +++ b/schema/vocab/coala.jsonld @@ -224,6 +224,18 @@ "rdfs:comment": "The context in which a Right may be exercised. User defined.", "rdfs:label": "rightContext" }, + { + "@id": "coala:rightType", + "@type": "rdf:Property", + "schema:domainIncludes": { + "@id": "coala:Right" + }, + "schema:rangeIncludes": { + "@id": "schema:Text" + }, + "rdfs:comment": "Defines the type of the Right (e.g. Copyright, License)", + "rdfs:label": "rightType" + }, { "@id": "coala:territory", "@type": "rdf:Property", From 7e59a7d589c755bb6821481d0e09205d883beaad Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Tim=20Daubensch=C3=BCtz?= Date: Tue, 20 Nov 2018 10:39:36 +0100 Subject: [PATCH 3/5] Change Copyright to rightType:Copyright --- README.md | 84 +++++++++++++++++++++++++----------------------- schema/README.md | 54 ++++++------------------------- 2 files changed, 52 insertions(+), 86 deletions(-) diff --git a/README.md b/README.md index 5d8aa6a..02104c2 100644 --- a/README.md +++ b/README.md @@ -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 @@ -1403,6 +1403,7 @@ satisfy the consolidated requirements of: "@context": "http://coalaip.schema/", "@type": "Right", "@id": "", + "rightType": "License", "usages": "all|copy|play|stream|...", "territory": "", "context": "inflight|inpublic|commercialuse...", @@ -1417,7 +1418,7 @@ satisfy the consolidated requirements of: "@type": "Date", "@value": "2017-01-01" }, - "source": "", + "rightsOf": "", "license": "" } ``` @@ -1434,6 +1435,7 @@ this in mind, the implementation in IPLD (on IPFS) is favoured: { "@context": { "/": "" }, "@type": "Right", + "rightType": "License", "usages": "all|copy|play|stream|...", "territory": { "/": "" }, "context": "inflight|inpublic|commercialuse...", @@ -1448,27 +1450,25 @@ this in mind, the implementation in IPLD (on IPFS) is favoured: "@type": "Date", "@value": "2017-01-01" }, - "source": { "/": "" }, + "rightsOf": { "/": "" }, "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: @@ -1476,7 +1476,8 @@ We propose: // In JSON-LD { "@context": "http://coalaip.schema/", - "@type": "Copyright", + "@type": "Right", + "rightType": "Copyright", "rightsOf": "", "territory": "", "validFrom": { @@ -1493,6 +1494,7 @@ We propose: { "@context": { "/": "" }, "@type": "Copyright", + "rightType": "Copyright", "rightsOf": { "/": "" }, "territory": { "/": "" }, "validFrom": { @@ -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 @@ -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: @@ -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 diff --git a/schema/README.md b/schema/README.md index 4cc2e3f..f52e44a 100644 --- a/schema/README.md +++ b/schema/README.md @@ -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": "/Copyright", - "@type": "rdfs:Class", - "rdfs:subClassOf": { - "@id": "schema:Intangible" - }, - ... -} - // Right Class { "@id": "/Right", @@ -582,7 +572,7 @@ As no existing schema.org vocabulary fits the RRM's notion of a `Right` or [COAL "@id": "/rightsOf", "@type": "rdf:Property", "schema:domainIncludes": { - "@id": "coala:Copyright" + "@id": "coala:Right" }, "schema:rangeIncludes": { "@id": "schema:CreativeWork" @@ -593,34 +583,13 @@ As no existing schema.org vocabulary fits the RRM's notion of a `Right` or [COAL ... } -// Source Property -{ - "@id": "/source", - "@type": "rdf:Property", - "schema:domainIncludes": { - "@id": "coala:Right" - }, - "schema:rangeIncludes": { - "@id": "coala:Copyright" - }, - "owl:equivalentProperty": { - "@id": "dc:source" - }, - ... -} - // Territory Property { "@id": "/territory", "@type": "rdf:Property", - "schema:domainIncludes": [ - { - "@id": "coala:Copyright" - }, - { + "schema:domainIncludes": { "@id": "coala:Right" - } - ], + }, "schema:rangeIncludes": { "@id": "schema:Place" }, @@ -648,9 +617,6 @@ As no existing schema.org vocabulary fits the RRM's notion of a `Right` or [COAL "@id": "/validFrom", "@type": "rdf:Property", "schema:domainIncludes": [ - { - "@id": "coala:Copyright" - }, { "@id": "coala:Right" }, @@ -677,9 +643,6 @@ As no existing schema.org vocabulary fits the RRM's notion of a `Right` or [COAL "@id": "/validThrough", "@type": "rdf:Property", "schema:domainIncludes": [ - { - "@id": "coala:Copyright" - }, { "@id": "coala:Right" }, @@ -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." @@ -724,8 +687,9 @@ An example of a `Copyright` and a derived `Right`: "http://schema.org/", "" ], - "@type": "/Copyright", + "@type": "/Right", "@id": "", + "rightType": "Copyright", "rightsOf": "", "territory": "", "validFrom": "2016-01-01", @@ -740,7 +704,7 @@ An example of a `Copyright` and a derived `Right`: ], "@type": "/Right", "@id": "", - "source": "", + "rightsOf": "", "usageType": ["all", "copy", "play"], "territory": "", "rightContext": ["inflight", "inpublic", "commercialuse"], @@ -759,7 +723,7 @@ An example of a `Copyright` and a derived `Right`: "http://schema.org/", "" ], - "@type": "/Copyright", + "@type": "/Right", "rightsOf": { "/": "" }, "territory": { "/": "" }, "validFrom": "2016-01-01", @@ -773,7 +737,7 @@ An example of a `Copyright` and a derived `Right`: { "/": "" } ], "@type": "/Right", - "source": { "/": "" }, + "rightsOf": { "/": "" }, "usageType": ["all", "copy", "play"], "territory": { "/": "" }, "rightContext": ["inflight", "inpublic", "commercialuse"], From 8167a21807fb70943a799be660525418f019d1bc Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Tim=20Daubensch=C3=BCtz?= Date: Tue, 20 Nov 2018 13:22:54 +0100 Subject: [PATCH 4/5] Copyright => Right --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 02104c2..08a8c1d 100644 --- a/README.md +++ b/README.md @@ -1493,7 +1493,7 @@ We propose: // In IPLD { "@context": { "/": "" }, - "@type": "Copyright", + "@type": "Right", "rightType": "Copyright", "rightsOf": { "/": "" }, "territory": { "/": "" }, From d965af195a76006405143fb3c8c40f4f6ae05760 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Tim=20Daubensch=C3=BCtz?= Date: Thu, 6 Dec 2018 10:45:29 +0100 Subject: [PATCH 5/5] Add RightsConflict --- README.md | 65 +++++++++++++++++++++++++++++++++++++++++++++++++++---- 1 file changed, 61 insertions(+), 4 deletions(-) diff --git a/README.md b/README.md index 08a8c1d..357bfd9 100644 --- a/README.md +++ b/README.md @@ -1789,17 +1789,74 @@ silently changed after-the-fact as any changes will cause their IPLD hashes to a ### The RRM `RightsConflict` Entity -TODO: +As mentioned in the section earlier, COALA IP's entities are created by independent users +rather than trusted central authorities. We are hence not able to determine whether or not +a `Right` registration is valid. There might be cases where two or more `Right`s are +conflicting with each other or where a sublicense is wrongly derived. In these cases, the +RRM recommends the implementation of a `RightsConflict` entity to counteract fraudulent +claims. These `RightsConflict` entities provide a healing mechanism for the ontology and, +using a staking approach, a way to settle conflicts through a private arbitration court +directly on the blockchain. + +The RRM's minimum set of required properties include: + +- **ConflictStatus**: The status of the `RightsConflict` (e.g. unresolved, resolved) +- **ValidPeriod**: Defines the time period during which the `RightsConflict` is maintained + (e.g from 01.01.2011 to 01.01.2015). + -- See other introductory sections of LCC entities. Use same structure to describe the entity +Additionally, an RRM `RightsConflict` can have the following outgoing references: +- Links to `Right` (`2 - n`; 2-to-many): *ConflictingRight* #### Proposed Transformation -TODO: +As we assume that all data is stored on immutable ledgers, we propose to not store +the property `ConflictStatus` within the `RightsConflict` JSON. Instead we recommend +encoding it as a status that is part of an private arbitration game. Additionally, +we propose to embed `ValidPeriod` as is described in the RRM. As there may be two +`Right`s linked in the `RightsConflict` entitiy, we propose the following syntax: -- See other introductory sections of LCC entities. Use same structure to do the transformation +```javascript +// In JSON-LD +{ + "@context": "http://coalaip.schema/", + "@type": "RightsConflict", + "supersedingRight": "", + "conflictingRight": "" + "validFrom": { + "@type": "Date", + "@value": "2016-01-01" + }, + "validTo": { + "@type": "Date", + "@value": "2017-01-01" + }, + +} + +// In IPLD +{ + "@context": "http://coalaip.schema/", + "@type": "RightsConflict", + "supersedingRight": "", + "conflictingRight": "" + "validFrom": { + "@type": "Date", + "@value": "2016-01-01" + }, + "validTo": { + "@type": "Date", + "@value": "2017-01-01" + }, + +} +``` +In case of a private arbitration blockchain court like [Kleros.io](https://kleros.io/) +and [Mattereum.com](https://www.mattereum.com/) both `Right`s in question should be +taken into escrow and, depending on the court's outcome, one of them should be sent +to a non-retrievable address so that the `Right` gets "burned". ### Generating Verifiable Claims