Review for W3C POE Deliverables - perspective of RightsStatements.org

Dear all,

This mail is the first of a series of emails commenting on the POE Use Cases, Information Model and Vocabulary.

First, I would like to congratulate the group for such great work.
Second I have to apologize for not having the time to raise comments on github. You will understand when seeing my other mails, that it was just impossible for me.

I'm going to start here with some comments from the perspective of RightsStatements.org, an initiative in which Mark Matienzo (Stanford) and myself (Antoine Isaac, Europeana and VU Amsterdam) are involved. This is also refered to as the 'Europeana/DPLA use case' in the POE Use Cases.
The following comments have been worked on by both Mark and I.


1. General feedback on POE Use Cases (https://www.w3.org/TR/2017/WD-poe-ucr-20170223/)

Are the requirements identified in this document (https://www.w3.org/TR/2017/WD-poe-ucr-20170223/#Requirements) referred in other POE documents? It would be great to see which requirements have been implemented or not, and by which specific item of the Information Model or Vocabulary. Unless all have been met? It's not very clear. Some requirements have been stricken out, indicating de-prioritization. But it could still be that some of the ones you judge important are only partially met.

Also not all requirements for use cases have been captured. To start with, the RightsStatements.org case could be used to motivate more requirements. In addition to the current focus, rightsstatements.org can articulate other use cases paired with existing requirements, namely:
* POE.R.V.15 - for our statements NoC-CR and NoC-OKLR
* Perhaps new entries under POE.R.E (Encoding) following our use of `relatedURL` parameter for statements that need a link to a human-readable legal piece
* Documenting cases of rights status expiry, which is perhaps relevant to POE.R.DM.06
Would you accept new/revised use cases?

As an other example, I'm not sure POE says anything about propagation of deletions (POE.UC.23). The use case POE.UC.23 had just one general requirement about having complex constraints…


2. Europeana/DPLA use case (https://www.w3.org/TR/2017/WD-poe-ucr-20170223/#POE.UC.27)

First, thanks for including us, it is really good to have connections between our initiatives. And we'll try to remain compatible with POE specifications. Especially in our modeling work (http://rightsstatements.org/files/170106requirements_for_the_technical_infrastructure_for_standardized_international_rights_statements_v1.2.pdf, p17) we have tried to reuse odrl:inheritFrom.

Our first comment here is about representation issues for our case. In the material we had written on the the ODRL community Wiki
https://www.w3.org/community/odrl/wiki/Europeana/DPLA_In_Copyright_-_Educational_Use_Only
we had proposed to represent our right statement the following way:

    <http://rightsstatements.org/rs/ic-edu> a dcterms:RightsStatement , odrl:Policy ;
      skos:prefLabel "In Copyright - Educational Use Only"@en ;
      odrl:permission [
                 odrl:action odrl:use ;
                 odrl:constraint [
                       odrl:operator odrl:eq ;
                       odrl:purpose <http://rightsstatements.org/purpose/education> # This would be preferably from an existing namespace, not ours.
                     ]
          ] .

Note especially the use of odrl:purpose as a property, following the spec in the previous ODRL ontology: https://www.w3.org/ns/odrl/2/ODRL21#term-purpose
But this has now changed, it seems, with odrl:purpose being an instance, and the whole stuff about constraint operands being quite different (http://w3c.github.io/poe/model/#constraint)
As I understand the new POE vocabulary the example should now be

    <http://rightstatements.org/rs/ic-edu> a dcterms:RightsStatement , odrl:Policy ;
      skos:prefLabel "In Copyright - Educational Use Only"@en ;
      odrl:permission [
         odrl:action odrl:use ;
         odrl:constraint [
               odrl:leftOperand odrl:purpose ;
               odrl:operator odrl:eq ;
               odrl:purpose <http://rightstatements.org/purpose/education>
          ]
      ].

Can you confirm this? And would you accept new/revised use cases?

Note that this is not implemented on our side yet. The current representations of statements (https://github.com/rightsstatements/data-model/blob/master/rights-statements.ttl) are simpler. But it will become important in the future.

Also, I guess in the requirements related to our case, a ‘vocabulary of purpose’ could have been noted (like the ‘education’ one used above). Or at least a mechanism to extend existing purposes/actions (there is a comment on the other feedback mail sent at the same time as this one). We've not created the purpose http://rightstatements.org/purpose/education that is used in the example, yet. And we would prefer not to have to maintain such general concepts ourselves...

Finally, a couple of editorial comments: it would be better to name is a RightsStatements.org use case; mentioning Europeana and DPLA in the body is fine :-) Also you should remove Riccardo Albertoni - Riccardo worked with me only on data quality - and add Mark Matienzo instead.


3. Relation to other standard frameworks for expressing rights statements (esp. Creative Commons and DC)

Our RightsStatements.org use case raises the question between POE and other standard frameworks to represent rights/licenses. But I believe the issue goes much beyond our own case.

First, the POE pattern is centered on rights statements (which for us correspond to the POE "policy" notion). And the property that indicates the policy that applies to an asset (odrl:target) goes from the policy to the asset.
The most common pattern, and we believe the one that fits most application scenarios, is the one where links in the other direction and use properties that are usually used for representing metadata on assets, like “simple” (DC) properties. Our (rightsstatements.org) specific approach to this can be seen in the "Class for Rights Statements" and "Object Metadata Examples" at http://rightsstatements.org/files/170106requirements_for_the_technical_infrastructure_for_standardized_international_rights_statements_v1.2.pdf
It's also in the ccRel W3C submission: https://www.w3.org/Submission/ccREL/ and https://creativecommons.org/ns (using cc:license/xhtml:license)
But I guess you're already quite familiar with the pattern anyway…
Of course I’m not saying that the ODRL pattern is bad. It is fully legit, imho. But considering existing practices, I think the matter of the equivalence between patterns should be given a much more prominent place, and be ironed out to remove any doubts one could have.

As a matter of fact it seems you are aware of the problem: the RDF/OWL document refers to a correspondence between expressing rights statements with dct:license and the “official” pattern (section 5.1.1, https://www.w3.org/TR/2017/WD-odrl-vocab-20170223/#rdfowl )
This goes in the right direction, but:
- in fact the axiom is not presented very explicitly: it is refered to as ‘this axiom’ but not spelled out
- we are not sure that dct:license is the right property (level) for such axiom. We consider dct:rights (a super-property of dct:license) to be a more appropriate level for such linking, as some policies (rights statements) are not necessarily licenses.
- I really don’t see why this is in a section introducing an ‘RDF/OWL encoding’. It is not a matter that seems specific to an OWL ontology. And in fact it doesn't seem to appear in the RDF/Turtle serialization of the ontology: http://w3c.github.io/poe/vocab/ODRL22.ttl . It may be better to devote a specific section of another document, or even a document of its own (maybe one that would tackling the following issue at the same time?)


Second, there are other frameworks for modeling rights, notably the Creative Commons ccRel vocabulary (NB: I’m not intending to be complete, only making comments about the ones I’m most familiar with and the most relevant for rightsstatements.org).
There used to be a sort of mapping between ODRL and ccRel: https://www.w3.org/community/odrl/work/cc/

In the new spec, the CC elements seem to be mapped to, but they are only "defined" in the 'deprecated terms' annex https://www.w3.org/TR/2017/WD-odrl-vocab-20170223/#deprecate
In fact they appear as actions at https://www.w3.org/TR/2017/WD-odrl-vocab-20170223/#term-Action but the hyperlink refer directly to the annex.
If these are still important actions, it would be good to list them as "real" POE vocabulary elements, even if the classes/properties are from another namespace. See the approach in DCAT's document, e.g. https://www.w3.org/TR/vocab-dcat/#Property:dataset_title

Also, it would be useful to revisit the mapping and see if the approach that lead to deprecation-following-mapping is consistently applied. Especially, ccRel has Attribution but POE still has a resource for it in the ODRL namespace:https://www.w3.org/TR/2017/WD-odrl-vocab-20170223/#term-attribute


Finally, Creative Commons and others define generic rights statements and licenses that can be re-used for expressing asset-level policies. We think this can be done in POE using POE's inheritance pattern, where an asset-specific policy inherits from a more general policy (maybe an odrl:Set). This how we've understood it when writing our RightsStatements.org whitepaper http://rightsstatements.org/files/170106requirements_for_the_technical_infrastructure_for_standardized_international_rights_statements_v1.2.pdf , p17. If our representation is right, we feel there is a missed opportunity for relating POE to sets of existing policies like Creative Commons. CC examples could have been introduced in the POE information model in 3.1.5, instead of using only example.org policies.

Received on Saturday, 29 April 2017 23:34:53 UTC