Closed simonstey closed 7 years ago
I have a point against Policies indicating a specific type mandatorily. I also have a question on the RDF style.
When talking to non-ODRL people, the idea of policy was readily grasped by everyone and declaring the odrl:Policy was straightforwardly understood. However, using odrl:Set was confusing (set being too polysemical a word).
Indeed, both "policy" and "set" can be in the RDF triples declaring a policy, but the former is redundant.
Opinion#1: Don't make this mandatory.
What is the preferred style when redundantly declaring the type? Example1:
odrl:prohibition [
a odrl:Prohibition ;
odrl:action odrl:use;
] .
Example 2:
odrl:prohibition [
odrl:action odrl:use;
] .
Example1 can be inferred from Example2 and the ODRL Ontology. Do we really need to declare the type with "a odrl:Prohibition ;".?
Opinion #2. It is arguable but my opinion is not declaring the redundant triple, so that the code remains minimal
@vroddon Are you OK with @simonstey request to show "type" as a class in the IM?
So Policy would look like:
@vroddon Opinion 1:
I would be OK to make type optional - AND to even deprecate "Set" as it is meaningless (just use Policy by itself) ?
Opinion 2:
I assume Example 2 is fine. (Good stuff for Best Practices?)
@simonstey I am not sure of having understood. As of today, the recommended practice is this:
odrl:prohibition [
a odrl:Prohibition ;
odrl:action odrl:use;
] .
Besides the representation in the diagram... how would it be in Turtle?
@riannella
I would be OK to make type optional - AND to even deprecate "Set" as it is meaningless (just use Policy by itself) ?
Perhaps we should raise this issue to confirm? I agree indeed but I just added the "Needs WG Decision".
@vroddon hm? is it about verbosity of the examples only or do you mean in general?
Oh! I don't understand the diagram, i.e., I don't know how to produce examples from the diagram.
WG agreed (8 may) to adopt subclass model for "types" and include current "policy types" in IM
The IM has been updated to replace the "type" property with subclasses. I have included 3 subclasses: Set, Offer, Agreement in the IM.
Do we need to include all the rest? (As the above 3 are the core policy subclasses...and the reader now has a better idea about what they mean in terms of additional constraints/cardinalities... the others in the Vocab/Profiles should be more clearer?)
All the JSON-LD examples in the IM now use @type.
Updated Vocab (removed the word "type"). Updated Figure.
Updated XML Encoding narrative.
Commit: 20a7992dc7965429e0c5f782a6083f6de795a4ab
I have included 3 subclasses: Set, Offer, Agreement in the IM.
Do we need to include all the rest? (As the above 3 are the core policy subclasses...and the reader now has a better idea about what they mean in terms of additional constraints/cardinalities... the others in the Vocab/Profiles should be more clearer?)
says who? do we define/specify/explain that somewhere? why is odrl:Offer
a core policy subclass but odrl:Request
isn't?
also:
A Policy MUST have the following properties:
- The uid identification of the Policy.
The Set Policy subclass:
- MUST include at least one Rule.
A Party has the following properties:
- A Party MUST have a uid identification of the Party
The Rule class has the following properties:
- A Rule MUST have a target Asset. Other relation values for Asset MAY be used.
consistency
As per the last ODRL Implementors Survey: https://www.w3.org/2016/poe/wiki/File:ODRLImplementationSurvey-2016-Dec-07.pdf
We also state:
"An ODRL Policy may be subclasssed to more precisely describe the context of use of the Policy that may include additional constraints that ODRL processors must understand. The Policy subclasses are documented in the ODRL Vocabulary [vocab-odrl] or in ODRL Profiles."
RE: "Consistency" - hOpEfUlLy fixed now ;-)
01ad75e0350c13432d4ff9a7fd82276a1149dd91
An ODRL Policy of subclass Set represents any combination of Rules. The Set Policy subclass is also the default subclass of Policy (if none is specified) ..
as in:
<http://example.com/policy:01>
a odrl:Policy;
odrl:permission [
a odrl:Permission ;
odrl:target <http://example.com/asset:9898> ;
odrl:action odrl:reproduce
] .
or as in:
<http://example.com/policy:02>
odrl:permission [
a odrl:Permission ;
odrl:target <http://example.com/asset:9898> ;
odrl:action odrl:reproduce
] .
... and does not assert any additional cardinalities or semantics.
in addition to what?
The Set Policy subclass has the following:
A Set MUST include at least one Rule
@simonstey As in your first example. Perhaps odrl:Set is equivalent class to odrl:Policy ?
removed: "and does not assert any additional cardinalities or semantics"
"..has the following requirements:"
I think for Set we leave it as Rule (as we don''t want to restrict them) but for Offer and Agreement we change Rule to "Permission or Prohibition" ?
"..has the following requirements:"
I would suggest phrasing it along the lines of:
An ODRL Policy of type Set MUST include at least one Rule.
An ODRL Policy of type Offer:
- MUST include at least one Permission or Prohibition .
MUST include at least one ..
I think for Set we leave it as Rule (as we don''t want to restrict them) but for Offer and Agreement we change Rule to "Permission or Prohibition" ?
thus permitting policies like:
<http://purl.org/NET/rdflicense/cc-by-nd2.0>
a odrl:Set;
rdfs:label "Creative Commons CC-BY-ND" ;
dct:publisher "Creative Commons" ;
odrl:permission cc:Reproduction ;
odrl:duty cc:Notice, cc:Attribution ;
odrl:prohibition cc:DerivativeWorks .
? that would be big news :O đź‘Ť
(@vroddon might want to chime in on this)
Done: 38b945c2c639cf51ec61ef9b7e24e498e3bc9fdc
Let Set be free :-)
@riannella @simonstey
Sorry if this was already discussed but... ...is there any reason for using/not using OWL Property restrictions? https://www.w3.org/TR/owl-ref/#Restriction
VĂctor
El 12/05/2017 a las 11:26, simon escribiĂł:
An ODRL Policy of subclass Set represents any combination of Rules. The Set Policy subclass is also the default subclass of Policy *(if none is specified)* ..
as in:
http://example.com/policy:01 a odrl:Policy; odrl:permission [ a odrl:Permission ; odrl:targethttp://example.com/asset:9898 ; odrl:action odrl:reproduce ] .
or as in:
http://example.com/policy:02 odrl:permission [ a odrl:Permission ; odrl:targethttp://example.com/asset:9898 ; odrl:action odrl:reproduce ] .
... and does not assert any additional cardinalities or semantics.
in addition to what?
The Set Policy subclass has the following: A Set MUST include at least one Rule
- has the following what?
- s/Rule/Prohibition or Permission/
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c/poe/issues/154#issuecomment-301029094, or mute the thread https://github.com/notifications/unsubscribe-auth/AFLs5anIxmZ1aDPixZMv8YVFkUK9B1cmks5r5CXAgaJpZM4NLFh3.
-- 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
There is no reason why not to.
What would it look like?
Clarification....(as we currently say Duty is for Permission only....)..
So in the example above, the duty at the Policy level means what?
@vroddon @riannella : what would we want to achieve with complex OWL statements? Do people use ODRL expressions to deduce new valid statements, or are we looking for a semantics to produce data checkers? There is a difference: the OWL semantics is not really good for checking purposes (unless it creates new statements that are in contradiction with others).
Lets leave ODRL as a "vocabulary" rather than an "ontology".
The Formal Semantics NOTE can take on the latter.
In the one hand, I am in favour of adding cardinality constraints, as this is a common practice not only for reasoning purposes. In the other hand, I am happy to get rid of them, as having a lightweight vocabulary is likely to gain wider attention.
Given that we have a Formal Semantics Note, I am also in favour of keeping the vocab as simple as possible.
Section 3.1 Policy:
Section 3.5.1 Permission:
While policy types are neither part of the current IM diagram [1] nor discussed in more detail in the IM at all, rule types are. They are, however, handled similarly in the Vocab.
so why not do the same in the IM too?
[1] https://github.com/w3c/poe/blob/e055b79b52922eb52942a7622cebe25df3c091f1/model/fig/00Model.png