w3c / poe

Permissions & Obligations Expression WG
Other
23 stars 18 forks source link

Difference between Policy Types and Rule Types #154

Closed simonstey closed 7 years ago

simonstey commented 7 years ago

Section 3.1 Policy:

A Policy MUST refer to the type indicating the specific type of Policy.

Section 3.5.1 Permission:

A Permission class is a specific type of Rule.

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

vroddon commented 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

riannella commented 7 years ago

@vroddon Are you OK with @simonstey request to show "type" as a class in the IM?

So Policy would look like:

screen shot 2017-05-02 at 11 20 50
riannella commented 7 years ago

@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?)

vroddon commented 7 years ago

@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?

vroddon commented 7 years ago

@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".

simonstey commented 7 years ago

@vroddon hm? is it about verbosity of the examples only or do you mean in general?

vroddon commented 7 years ago

Oh! I don't understand the diagram, i.e., I don't know how to produce examples from the diagram.

riannella commented 7 years ago

WG agreed (8 may) to adopt subclass model for "types" and include current "policy types" in IM

riannella commented 7 years ago

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

simonstey commented 7 years ago

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

riannella commented 7 years ago

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

simonstey commented 7 years ago

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

riannella commented 7 years ago

@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" ?

simonstey commented 7 years ago

"..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)

riannella commented 7 years ago

Done: 38b945c2c639cf51ec61ef9b7e24e498e3bc9fdc

Let Set be free :-)

vroddon commented 7 years ago

@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

riannella commented 7 years ago

There is no reason why not to.

What would it look like?

riannella commented 7 years ago

Clarification....(as we currently say Duty is for Permission only....)..

So in the example above, the duty at the Policy level means what?

iherman commented 7 years ago

@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).

riannella commented 7 years ago

Lets leave ODRL as a "vocabulary" rather than an "ontology".

The Formal Semantics NOTE can take on the latter.

vroddon commented 7 years ago

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.