Relation to other standard frameworks for expressing rights statements

[riannella]

@aisaac

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.

[riannella]

Proposal:

1 - update the IM to include a new property odrl:policy (hasPolicy)
(declare as sub-property of dc:rights and http://www.w3.org/ns/ma-ont#hasPolicy)

2 - Remove the "target asset" section from the RDF/OWL Encoding section in the Vocab.
(there will be an example in the IM)

3 - Remove deprecated terms as instances of Action

Comments:

1 - we kept odrl:attribute as an action as CC only has cc:attributionURL and cc:attributionName (which are not appropriate actions)

Question:

1 @aisaac Are you saying that an ODRL Policy can inherit a CC License?

[aisaac]

I'm sorry but I think this issue is too big for discussion. I want to answer your points, but I'm afraid that this will result in a long thread mixing different things. Would it be possible to at least try to separate what follows 'Second,' from what is after "First,"?

[riannella]

Sure, please create seperate issues for the discussion

[aisaac]

The "first" part is now in #184 .
The "second" part can still be discussed here.

[aisaac]

Your proposal 3 solves the inconsistency in the POE spec, but it doesn't solve this issue. If I understand well, removing deprecated terms as instances of Action would amount to fully deprecate them, which doesn't give the kind of correspondance I was hoping for. Yes an ODRL Policy can inherit a CC License. This would be a way to present some mapping at the level of instances (of policies) CC Licenses are instance of POE Policy I believe. Regarding your comment on odrl:attribute, it may be ok, but I'd prefer to look at this in the context of a fuller mapping.

…

On 18/05/17 04:32, Renato Iannella wrote: Sure, please create seperate issues for the discussion — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#158 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAnprX1ZL0xxDH5k6w0o3QkuxDTP6semks5r662igaJpZM4NNqQV>.

[aisaac]

I was asked to check issues I had raised. This one still remains.

[riannella]

Sorry @aisaac - can you be more specific as to which one still remains?

[aisaac]

Hi @riannella, sorry I should perhaps have been more explicit. While reviewing issues on which I had not much to add, I was looking at the entire thread on Github and didn't repeat my old comments. So for this issue my last comment (#158 (comment)) has not been answered, and thus I guess the issue thus remains. I really can't say more, I'm afraid.

…

On 19/06/17 03:00, Renato Iannella wrote: Sorry @aisaac <https://github.com/aisaac> - can you be more specific as to which one still remains? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#158 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAnprdzai9UM__AHQle-xOyizwSfXmF1ks5sFcgTgaJpZM4NNqQV>.

[riannella]

Ok....as you state above: "If these are still important actions..." We still note the CC-like terms we defined in ODRL as Actions, but we want them to use the actual CC terms URIs. (so they CC terms are more important, in this case.)

The example from Dcat is different. They want you to use those terms (and are not deprecating anything).

[aisaac]

For DCAT I just wanted to point at how they have documented such things. I.e. DCAT includes a 'title' property, but they say that for this dct:title should be used. I think this is quite the same situation as when you write "We still note the CC-like terms we defined in ODRL as Actions, but we want them to use the actual CC terms URIs. (so they CC terms are more important, in this case.)" What is important is that what DCAT recommends is explicit is in the DCAT documentation. Right now there is nothing in the POE documentation that reflects clearly what you say ("we want them to use the actual CC terms URIs. (so they CC terms are more important, in this case"). For example, if I want to allow or prevents commercial use of a resource, there is nothing that points me to https://creativecommons.org/ns#CommercialUse as a valid type of Action I could use. There is a reference to Commercialize at for example https://w3c.github.io/poe/vocab/#term-Action but it points directly to https://w3c.github.io/poe/vocab/#term-commercialize And this, I'm sorry to say, is not enough. It appears without any context or instruction in the 'deprecated' section, together with terms that are *really* deprecated. So I would think I cannot use it in a valid POE description. Using the pattern that the DCAT documentation uses for terms re-used from other namespace would be much more efficient, if indeed you want to encourage re-use of CC terms in POE descriptions.

[riannella]

I think it is slightly different case. DCAT says use a title and that must be dct:title. They never defined a dcat:title property...then a year later thought...hang on...we should not use that but re-use dct:title.

And looking at: https://www.w3.org/ns/dcat.ttl
I can't even see any of the dct properties ;-)

What if we added more narrative text to the Deprecated terms Appendix ?

[aisaac]

I insist it is the same case. The DCAT documentation uses this editorial trick to include Title in their model (it's visible next to the other elements) in the case where they have not created the 'real' property in their own namespace. Someone who would just look at the Turtle file would say, 'hey but why this stupid model doesn't give any title to datasets'? The DCAT documentation says 'well we do have a title in our model but we've been smart and re-used it from elsewhere instead of creating it ourselves'. We've done it in DQV recently too: see for example https://www.w3.org/TR/vocab-dqv/#dcterms:conformsTo You could add more narrative text to the Deprecated terms Appendix as you suggest, but I feel it won't be great: - it will not be very visible - much less visible than the editorial trick that DCAT uses. - it will be difficult and look awkward, because not all the elements in the Deprecated terms Appendix should be treated the same way. Again some elements there are truly deprecated (not in the model anymore) while other are 'delegated' to other namespace. So I'd really push for taking the DCAT editorial approach, which means for POE, and for the case of commercializing, that the URL https://w3c.github.io/poe/vocab/#term-Action that currently appears in the instances of odrl:Action at https://w3c.github.io/poe/vocab/#term-Action would now refer to a fully fledged HTML sub-section between https://w3c.github.io/poe/vocab/#term-attribute and https://w3c.github.io/poe/vocab/#term-compensate This section would have the usual definition box, except that instead of having an identifier in the ODRL namespace it would have an identifier in the CC namespace. Note that in accordance you should update the ODRL turtle file to declare cc:CommercialUse an instance of odrl:Action. Which is perfectly legit and would start to really answer my question on the mapping between CC and POE. Namely, for one of the CC permissions there is a mapping, and it is an rdf:type statement to odrl:Action. Then ideally you may have an annex that sums up all your mappings, including the discussion on cc:License vs dcmiterms:RightsStatements vs dcmiterms:License vs odrl:Policy that has been discussed at #184. But that could be the step afterwards. Am I making any sense?

[larsgsvensson]

Am I making any sense?

Yes

[vroddon]

I like a lot this approach El 21/06/2017 a las 12:21, aisaac escribió:

…

I insist it is the same case. The DCAT documentation uses this editorial trick to include Title in their model (it's visible next to the other elements) in the case where they have not created the 'real' property in their own namespace. Someone who would just look at the Turtle file would say, 'hey but why this stupid model doesn't give any title to datasets'? The DCAT documentation says 'well we do have a title in our model but we've been smart and re-used it from elsewhere instead of creating it ourselves'. We've done it in DQV recently too: see for example https://www.w3.org/TR/vocab-dqv/#dcterms:conformsTo You could add more narrative text to the Deprecated terms Appendix as you suggest, but I feel it won't be great: - it will not be very visible - much less visible than the editorial trick that DCAT uses. - it will be difficult and look awkward, because not all the elements in the Deprecated terms Appendix should be treated the same way. Again some elements there are truly deprecated (not in the model anymore) while other are 'delegated' to other namespace. So I'd really push for taking the DCAT editorial approach, which means for POE, and for the case of commercializing, that the URL https://w3c.github.io/poe/vocab/#term-Action that currently appears in the instances of odrl:Action at https://w3c.github.io/poe/vocab/#term-Action would now refer to a fully fledged HTML sub-section between https://w3c.github.io/poe/vocab/#term-attribute and https://w3c.github.io/poe/vocab/#term-compensate This section would have the usual definition box, except that instead of having an identifier in the ODRL namespace it would have an identifier in the CC namespace. Note that in accordance you should update the ODRL turtle file to declare cc:CommercialUse an instance of odrl:Action. Which is perfectly legit and would start to really answer my question on the mapping between CC and POE. Namely, for one of the CC permissions there is a mapping, and it is an rdf:type statement to odrl:Action. Then ideally you may have an annex that sums up all your mappings, including the discussion on cc:License vs dcmiterms:RightsStatements vs dcmiterms:License vs odrl:Policy that has been discussed at #184. But that could be the step afterwards. Am I making any sense? — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#158 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFLs5fuHQNZQFuC75GLzxj6S2wpaVd_6ks5sGO64gaJpZM4NNqQV>.

-- Víctor Rodríguez-Doncel D3205 - Ontology Engineering Group (OEG) Departamento de Inteligencia Artificial ETS de Ingenieros Informáticos Universidad Politécnica de Madrid Campus de Montegancedo s/n Boadilla del Monte-28660 Madrid, Spain Tel. (+34) 91336 3753 Skype: vroddon3

[riannella]

I've added a new section called "Collective Vocab" for this purpose and added all the CC terms as ODRL actions (we can add others?)

Comments?

commit: 2f5e18b

[aisaac]

Pfew this is a lot to review :-) But this is a good sign: the progress is fast! I will start with the vocabulary documentation at http://w3c.github.io/poe/vocab/ I will check the Turtle later, also because if I do this it will probably pre-empt on the review of SKOS usage that I've promised wrt #160... For the record I am using for CC reference the namespace doc at https://creativecommons.org/ns# Here are the comments: 1. I am not sure I see the need to group the actions 'imported' from CC in their own vocabulary at http://w3c.github.io/poe/vocab/#vocab-collective. Isn't it possible to merge them with the other actions defined by POE directly at http://w3c.github.io/poe/vocab/#actionsCommon What makes them essentially non-normative, and 'may be used', compared to the 'native POE' actions? 2. Why is this grouping called 'collective'? I really don't understand why this word is used here. Ar these actions always collective? Other POE actions cannot be collective? 3. I wouldn't list the equivalence to deprecated resources in the sections for the CC actions. I would keep them only in the section on deprecated terms http://w3c.github.io/poe/vocab/#deprecate. I.e. as information people who already know the deprecated terms, not as (unnecessary) information for the readers who did not know them anyway and will safely just read the 'main' sections, like http://w3c.github.io/poe/vocab/#term-Attribution NB: this should also be represented in the Turtle too, by representing the link only *from* the deprecated action *to* the new one, not the other way round. 4. The link between deprecated action and the replacement should probably be a SKOS matching link (skos:exactMatch or skos:closeMatch). Now it's "Equivalent Property:" but these actions are concepts, not properties. 5. I see that you have changed some definitions. E.g., "exercising rights for commercial purposes" becomes "Using the Work for commercial purposes". But this seems fine, as the original CC definitions are rather dodgy. Actually one has 'permits' in the definition ("permits commercial derivatives, but only non-commercial distribution"), the sort of issue I had spotted for POE, but which you have since then fixed :-) This said, cc:Attribution mentions copyright holder, and you don't: is it on purpose? I'd have thought Attribution can also be for copyright holders that are not the creators. Also I'm not sure why cc:Distribution is not about *re-*distribution. 7. I see that Share is now mapped to cc:Distribute, but there is also cc:Sharing. And when ODRL had minted a concept for Share (odrl:share) it was precisely defined as cc:Share ("permits commercial derivatives, but only non-commercial distribution"). What has happened so that cc:Share ended up being replaced by cc:Distribute? 8. cc:Distribution mentions "distribution, public display, and publicly performance" at https://creativecommons.org/ns#. This seems to include also odrl:present, odrl:play, etc. Are you sure that we can restrict the definition of cc:Distribution so that it's equivalent to the deprecated odrl:share? 9. "Share A Like" should be "Share Alike" ;-)

[simonstey]

scr, I had to "Share A Like" ;)

[riannella]

1. I initially was going to do that then thought are these actions part of the "ODRL Common Vocabulary"? (ie are these "ODRL" or from another source).
   Would users think these terms are ODRL terms?
   BTW, the ODRL Common Vocab is non-normative too.

2. Collective was an attempt to say we've "collected" these other terms from other sources that you may like to use...(but clearly not working ;-(

Thoughts from others? Should we move them to the Actions list in the ODRL Common Vocab?

3. OK.

4. Good point. Updated.

5. I originally took the definitions from here: https://www.w3.org/Submission/ccREL/
   I have updated them all now to be from https://creativecommons.org/ns#
   (although I think CC should spend more time on these definitions ;-)

And this is another reason why keeping these seperate from all the ODRL Common Vocab terms as we are not focussed on copyright.

6. this page intentionally left blank ;-)

7. Not sure...but fixed (added cc:Sharing as well)

8. Fixed in 7)

9. fixed

commit: 35f9f80

[riannella]

I have merged the CC terms into the common action list of terms.
And added a note to state these are from CC.
Commit: fbab143