Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Dc:license vocabulary hijacking? #286

Closed
iherman opened this issue Dec 19, 2017 · 20 comments
Closed

Dc:license vocabulary hijacking? #286

iherman opened this issue Dec 19, 2017 · 20 comments
Assignees
@nitmws @vroddon @riannella
Labels
Ontology Vocab

Comments

@iherman
Copy link
Member

iherman commented Dec 19, 2017

In section 3.5.2 of the vocab, on target policy, it says that hasPolicy has dc:license as a sub-property. This statement also appears in the ontology:

dct:license rdfs:subPropertyOf odrl:hasPolicy .

What this means is that if dc:license relates any two instances in the world, then odrl:hasPolicy is also a valid relationship for those instances. That is referred to as "ontology hijacking", ie, imposing an extra constraint on a vocabulary item that is not under the control of this group. This should not be done.

There are two possibilities:

  1. This is an editorial oversight and it should say hasPolicy subPropertyOf dct:license.
  2. This was the intention, but that should, in fact, be removed.

(No. 1 makes sense to me.)

A further question is either of those steps are taken, does that invalidate any of the implementations, i.e., does any of the implementations really make use of those terms? What about test cases? Obviously, the question is whether this is a substantive change or a honest but harmless mistake...

(This question came up during the PR Transition discussion with the Director.)
@nitmws
Copy link
Contributor

nitmws commented Dec 20, 2017

#158 and #184 are the reasons and background for this definition.
In short - the discussion in #184 shows this intention: an odrl:Policy can express many different rights related things, a subset of that is a license expression. This should be supported:

1. <http://example.org/asset/9991> odrl:hasPolicy <http://example.org/policy/1341243> .
2. <http://example.org/asset/9991> dct:license <http://example.org/policy/2534545> .

Re 1: Policy 1341243 expresses more than just a license, e.g. the transfer of ownership (sold, given away) of asset 9991
Re 2: Policy 2534545 expresses a license for asset 9991 and nothing else (see also Victor's Best Practice case)

That intention was discussed extensively but also the Director's concern that ODRL defines a super-property for an Dublin Core property is in the table.

So what are the options to solve that:
a/ remove dct:license rdfs:subPropertyOf odrl:hasPolicy . ... the semantics of hasPolicy "this asset has a Policy in which all target assets of the Rules are this asset" cannot be narrowed down to what the Rules express.
b/ creating a new property named e.g. hasLicense (with semantics similar to dct:license) with odrl:hasLicense rdfs:subPropertyOf odrl:hasPolicy . (Formal question: is this still possible - e.g. "as advised by the Director"?)

As #184 was a very long discussion @simonstey and @vroddon should share their views on that.

@iherman
Copy link
Member Author

iherman commented Dec 20, 2017

@nitmws, pardon me if I do not go down into the details of the mentioned issues (I was not part of those discussions). However, I am not sure I fully understand your comments above.

1. <http://example.org/asset/9991> odrl:hasPolicy <http://example.org/policy/1341243> .
...
Re 1: Policy 1341243 expresses more than just a license, e.g. the transfer of ownership (sold, given away) of asset 9991

But if so, isn't this expressed by saying that if there is an odrl:hasPolicy relationship between two resources then this implies a dct:license as well? This is perfectly expressed by using the axiom:

odrl:hasPolicy rdfs:subPropertyOf dct:license  .

which is not vocabulary hijacking, and which what I called 'honest mistake' in my original comment. The question is then if any implementation depends on the original axiom (which would be surprising, in fact).

@nitmws
Copy link
Contributor

nitmws commented Dec 20, 2017

@iherman I think the issue is: which one is the property with the broader semantics?
From how this was discussed in #184: odrl:hasPolicy should be the broader and dct:license be the narrower one. But as I'm primarily a reader of this issue in #184 it would be great to get a comment from @simonstey and @vroddon.

@benedictws
Copy link
Contributor

odrl:hasPolicy certainly has broader semantics than dct:license. The policy might, for example, express a regulation.

I sincerely doubt that any implementation depends on the axiom in question. I would be tempted to follow the suggestion of @nitmws : create a new ODRL property odrl:hasLicense with odrl:hasLicense rdfs:subPropertyOf odrl:hasPolicy .

@iherman
Copy link
Member Author

iherman commented Dec 20, 2017 via email

@simonstey
Copy link
Contributor

But if so, isn't this expressed by saying that if there is an odrl:hasPolicy relationship between two resources then this implies a dct:license as well? This is perfectly expressed by using the axiom:

odrl:hasPolicy rdfs:subPropertyOf dct:license .

iirc, back when we discussed #184 it was more about being able to integrate with existing license concepts.. I never thought about the issue of ontology hijacking.

and while I still think that

while every license is also a policy, every policy isn't necessarily a license

I'm perfectly fine with switching odrl:hasPolicy and dct:license (we should stick with either dc: or dct: though).

@simonstey
Copy link
Contributor

I am not sure what "broader semantics" mean in this context.

<http://example.com/policy:01>
    a odrl:Policy;
    odrl:prohibition [
        a odrl:Prohibition ;
        odrl:target ex:PartB ;
        odrl:action odrl:present ;
        odrl:assignee ex:Alice 
    ] .

ex:PartB odrl:hasPolicy <http://example.com/policy:01> .
odrl:hasPolicy rdfs:subPropertyOf dct:license .

dct:license: -> "A legal document giving official permission to do something with the resource."

<http://example.com/policy:01>
    a odrl:Policy;
    odrl:prohibition [
        a odrl:Prohibition ;
        odrl:target ex:PartB ;
        odrl:action odrl:present ;
        odrl:assignee ex:Alice 
    ] .

ex:PartB odrl:hasPolicy <http://example.com/policy:01> .
odrl:hasPolicy rdfs:subPropertyOf dct:license .
ex:PartB dct:license <http://example.com/policy:01> .

broader as in -> it's questionable whether <http://example.com/policy:01> matches the description of being a "A legal document giving official permission to do something with the resource."

@vroddon
Copy link
Contributor

vroddon commented Dec 20, 2017 via email

@vroddon
Copy link
Contributor

vroddon commented Dec 20, 2017 via email

@riannella
Copy link
Contributor

Firstly, this issue does not impact any of the implementations for CR as we did not have any test cases related to this issue.

@riannella
Copy link
Contributor

This was our intention:

What this means is that if dc:license relates any two instances in the world, then odrl:hasPolicy is also a valid relationship for those instances.

But not the other way round.

So, if W3C formally thinks this is hijacking - then our only option is to remove the statement.

@iherman
Copy link
Member Author

iherman commented Dec 20, 2017

@vroddon: the issue is not really technical but, instead, procedural and social. We do have a term (dct:license) that is defined and maintained by a reputable organization (DCMI). Changing/modifying the semantics of a term defined by DMCI should not be done without a synchronization with those who are responsible for it.

We could get into contact with the DCMI to decide with them whether it is o.k. for each and every dct:license relationship to imply an odrl:hasPolicy. If they agree, then we would be fine doing this. But just as we would not be happy if a third party decided to change/extend the semantics of an ODRL term without our approval, due diligence would require for us to contact DCMI.

@iherman
Copy link
Member Author

iherman commented Dec 20, 2017

@riannella, if that is the WG-s decision, then the next question is whether the implementations would be affected. You seem to say that the answer is no, but I think we should have a documented statement on that from our three CR implementers...

@riannella
Copy link
Contributor

@benedictws @nitmws @vroddon - does this affect your implementations at all ?
(if we remove the ct:license rdfs:subPropertyOf odrl:hasPolicy statement) ?

@vroddon
Copy link
Contributor

vroddon commented Dec 20, 2017 via email

@vroddon
Copy link
Contributor

vroddon commented Dec 20, 2017

I confirm from the UPM side that its implementation is not affected by the chagen.

@benedictws
Copy link
Contributor

The TR implementation is not affected by the change.

riannella added a commit that referenced this issue Dec 20, 2017
@riannella
Removed (informative) dc:license subproperty of hasPolicy statement #286
0206295
@riannella
Copy link
Contributor

Getting late here and assuming @nitmws agrees with the consensus.
I have made the changes and pushed all on github

@nitmws
Copy link
Contributor

nitmws commented Dec 20, 2017

Sorry for the late reply, I was completely taken this afternoon by IPTC working group calls ...
I agree to the consensus.

@riannella
Copy link
Contributor

Completed

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@nitmws nitmws

@vroddon vroddon

@riannella riannella

Labels
Ontology Vocab
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
6 participants
@iherman @nitmws @benedictws @vroddon @simonstey @riannella