-
Notifications
You must be signed in to change notification settings - Fork 18
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
Dc:license vocabulary hijacking? #286
Comments
#158 and #184 are the reasons and background for this definition.
Re 1: Policy 1341243 expresses more than just a license, e.g. the transfer of ownership (sold, given away) of asset 9991 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: As #184 was a very long discussion @simonstey and @vroddon should share their views on that. |
@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.
But if so, isn't this expressed by saying that if there is an
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). |
@iherman I think the issue is: which one is the property with the broader semantics? |
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: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 <https://github.com/nitmws> : create a new ODRL property odrl:hasLicense with odrl:hasLicense rdfs:subPropertyOf odrl:hasPolicy .
I am not sure what "broader semantics" mean in this context. Are we sure that odrl:hasPolicy being a _subproperty_ of dct:license does not cover that?
|
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
I'm perfectly fine with switching |
<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 |
Dear all,
Ontology hijacking was first (and formally) defined by Aidan Hogan in
2009 (see page 14 [1]), in plain words said to be "/the redefinition by
third parties of external classes/properties such that reasoning over
data using those external terms is afected/" (see [2]). The problem
naturally appeared in the context of /reasoning on large scale RDF
datasets/ --but already in [1] an immediate and easy solution was given:
to pay attention to the sources' authority.
Out of this context, stating facts about other's ontology is not a bad
practice. Moreover, it is a necessary practice, well aligned with the
RDF foundations. I dare to quote the RDF concepts in [3]:
To facilitate operation at Internet scale, *RDF is an open-world
framework that allows anyone to say anything about anything*. In
general, it is not assumed that all information about any topic is
available. A consequence of this is that RDF cannot prevent anyone
from making nonsensical or inconsistent assertions, and applications
that build upon RDF must find ways to deal with conflicting sources
of information.
Hence, *my opinion is firm about leaving things as they are now*.
Regards,
Víctor
[1] A. Hogan, A. Harth, and A. Polleres. Scalable Authoritative OWL
Reasoning for the Web.Int. J. Semantic Web Inf. Syst., 5(2), 2009
[2] Aidan Hogan, Andreas Harth, Alexandre Passant, Stefan Decker, Axel
Polleres, Weaving the pedantic web. In Christian Bizer, Tom Heath, Tim
Berners-Lee, and Michael Hausenblas
(Eds.), Proceedings of the WWW2010 Workshop on Linked Data on the Web,
LDOW 2010, Raleigh, USA, April 27, 2010, volume 628 of CEUR Workshop
Proceedings, CEUR-WS.org, 2010. URL
http://ceur-ws.org/Vol-628/ldow2010_paper04.pdf
[3] https://www.w3.org/TR/2002/WD-rdf-concepts-20020829/#xtocid48014
El 19/12/2017 a las 19:20, Ivan Herman escribió:
…
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.)
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
<#286>, or mute the thread
<https://github.com/notifications/unsubscribe-auth/AFLs5UCuPiqWswcJI74B_ZR1KOWstdeOks5tB_6FgaJpZM4RHXV8>.
--
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 3672
Skype: vroddon3
|
I strongly disagree.
Every license is a policy, but not every policy is a license.
Whereas license is defined "A legal document giving official permission
to do something with the resource.", I do see policies as broader as
they are not necessarily 'legal documents' nor are restricted solely to
permissions.
Regards,
Víctor
El 20/12/2017 a las 13:09, simon escribió:
… I'm perfectly fine with switching |odrl:hasPolicy| and |dct:license|
(we should stick with either |dc:| or |dct:| though).
--
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 3672
Skype: vroddon3
|
Firstly, this issue does not impact any of the implementations for CR as we did not have any test cases related to this issue. |
This was our intention:
But not the other way round. So, if W3C formally thinks this is hijacking - then our only option is to remove the statement. |
@vroddon: the issue is not really technical but, instead, procedural and social. We do have a term ( We could get into contact with the DCMI to decide with them whether it is o.k. for each and every |
@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... |
@benedictws @nitmws @vroddon - does this affect your implementations at all ? |
In such a case, I change my opinion.
Whereas I fiercely defend my standpoint with respect to personal
statements (I want to be able to speak about DublinCore, Trump or God),
I understand our document is produced by W3C and I dont want the
organisation to be qualified as impolite. A softer approach would be
perhaps using SKOS.
By the way, you may like this tool: http://graphite.ecs.soton.ac.uk/checker/
Víctor
El 20/12/2017 a las 13:31, Ivan Herman escribió:
…
@vroddon <https://github.com/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.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#286 (comment)>, or
mute the thread
<https://github.com/notifications/unsubscribe-auth/AFLs5bbBvE0d8Glf3hRM3rL0pkCpvaE9ks5tCP4OgaJpZM4RHXV8>.
--
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 3672
Skype: vroddon3
|
I confirm from the UPM side that its implementation is not affected by the chagen. |
The TR implementation is not affected by the change. |
Getting late here and assuming @nitmws agrees with the consensus. |
Sorry for the late reply, I was completely taken this afternoon by IPTC working group calls ... |
Completed |
In section 3.5.2 of the vocab, on target policy, it says that
hasPolicy
hasdc:license
as a sub-property. This statement also appears in the ontology:What this means is that if
dc:license
relates any two instances in the world, thenodrl: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:
hasPolicy subPropertyOf dct:license
.(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.)
The text was updated successfully, but these errors were encountered: