search

w3c / poe

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

Compatibility with common patterns for linking assets to policies #184

Closed aisaac closed 7 years ago

aisaac commented 7 years ago

Split from #158 , in the context of https://lists.w3.org/Archives/Public/public-poe-comments/2017Apr/0005.html :

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:

aisaac commented 7 years ago

From @riannella at https://github.com/w3c/poe/issues/158#issuecomment-299088960

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)

aisaac commented 7 years ago

@riannella this ticket contains the "first" part of #158 can you assign and label it please?

aisaac commented 7 years ago

Reactions to the proposal:

  1. This can be fine, but

    • why not odrl:hasPolicy instead of odrl:policy?
    • regarding your mapping to MO: wouldn't the property be equivalent (sameAs) mo:hasPolicy? (there might be hidden semantic traps in a strict equivalence, but I must suggest it still :-) )
    • regarding your mapping to DC: wouldn't the property be a super-property of dc:rights?
    • you shouldn't forget an inverse axiom between odrl:target and the new property

  2. OK!

riannella commented 7 years ago

Added hasPolicy to IM (section 2.1.4) and to Vocab.

Commit cc1838063977889e3af0ae5bfde965c7c53af472

aisaac commented 7 years ago

I'm going to wait for the answers re. the mapping of this property, but in the meantime I've checked the updates to the IM and Vocabulary. My only comment is about when both hint that the Asset "is assumed to be" the target of the Policy. Doesn't the group want to make this stricter and say that the Asset is the target of the Policy? This is what I was suggesting when point that there could be an inverse axiom between odrl:target and this new property.

vroddon commented 7 years ago

I had documented the use of dct:license as a best practice: https://www.w3.org/2016/poe/wiki/Best_Practices#3._How_to_grant_Alice_the_permission_to_use_an_asset_.28III.29

Should we replace dct:license by odrl:hasPolicy? Should we keep both?

aisaac commented 7 years ago

@vroddon are suggesting to replace odrl:hasPolicy by dct:license in the ODRL spec? Or to replace dct:license in your example by odrl:hasPolicy?

simonstey commented 7 years ago

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

vroddon commented 7 years ago

I would advice to have a odrl:policy and recommend it as best practice, but tolerate dct:license. dct:license is defined as:

A legal document giving official permission to do something with the resource.

This may not be always the case.

As a comparison cc:license (see https://creativecommons.org/schema.rdf) is a property defined to be the same (owl:sameAs) http://www.w3.org/1999/xhtml/vocab#license but subproperty of http://purl.org/dc/terms/license"

aisaac commented 7 years ago

For rightsstatements.org we had a bit of a hard time navigating in the landscape of existing classes of policies/statements and the properties available to connect to them (see pages 7-8-9 at http://rightsstatements.org/files/170106requirements_for_the_technical_infrastructure_for_standardized_international_rights_statements_v1.2.pdf)

But indeed we ended up judging that dct:license was too specific for our rightstatements (though it could be used for some). We opted for dct:rights as the most general level of property relevant. Still it may be that even dct:rights is too specific for ODRL. Some policies may not be about rights, may they? In which case we'd have the hierarchy dct:license subPropertyOf dct:rights subPropertyOf odrl:hasPolicy

That said it could be that dct:rights can have values that are not really specifying permissions and obligations. I.e. a string like "copyright holder: X" is not really saying anything about what should/can be done. In this case dct:rights is not really comparable with odrl:hasPolicy and the only hierarchical link that's correct is dct:license subPropertyOf odrl:hasPolicy

@vroddon the specialization links in the CC license vocabulary (CCrel) should be taken with a pinch of salt. When working on rightstatements.org we were a bit puzzled by the subclass/property relations, and we asked some friends at CC. Their (unofficial) answer was that dct:RightsStatement and LicenseDocument did not exist until 2008 and some CCrel decisions predate this. Ideally CCrel should be updated so that cc:license is a subproperty of dct:rights rather than dct:license and cc:License a subclass of dct:RightsStatement rather than dct:LicenseDocument. And in fact CCrel should ideally have used them directly rather than creating cc:License...

aisaac commented 7 years ago

I forgot to point out that even the single axiom dct:license subPropertyOf odrl:hasPolicy would still enable to present best practices like @vroddon 's https://www.w3.org/2016/poe/wiki/Best_Practices#3._How_to_grant_Alice_the_permission_to_use_an_asset_.28III.29 without changing them. I.e. they'd be not only 'tolerated': they would use a property that is well used in the field, while being compatible with ODRL's general picture (thanks to the subproperty axiom).

riannella commented 7 years ago

Updated the narrative to say: "...MUST be inferred to be the target Asset..."

Added: owl:inverseOf :target ;

Added axiom: dct:license rdfs:subPropertyOf odrl:hasPolicy .

commit: b6987fa58d84f84f047e79ae6d959be54c4a1d83

@vroddon suggest the examples use odrl:hasPolicy

simonstey commented 7 years ago

Added: owl:inverseOf :target ; Added axiom: dct:license rdfs:subPropertyOf odrl:hasPolicy .

what does this mean for XML?

riannella commented 7 years ago

This is beyond XML capabilities - unless implementors directly code this support.

aisaac commented 7 years ago

As said in another ticket, at this point I have trouble judging the new global picture. I have to voice this caveat for the future, if I spot something I have forgotten :-) But in the meantime I think the changes mentioned in this ticket give a very appropriate answer to my original comment. And that it be closed. Thanks!

riannella commented 7 years ago

thanks for your feedback and followup

simonstey commented 7 years ago

3.4.3 Has Target Policy:

Note: The Asset being identified MUST be inferred to be the target Asset of all of the Rules of the Policy.

+

Added: owl:inverseOf :target ;

+

Valid Policy:

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

=

Invalid Policy:


# inferred
ex:PartA odrl:hasPolicy <http://example.com/policy:01> .
ex:PartB odrl:hasPolicy <http://example.com/policy:01> .

# becomes invalid because not >all< rules of the policy have 
# both ex:PartA and ex:PartB as their target
<http://example.com/policy:01>
    a odrl:Policy;
    odrl:permission [
        a odrl:Permission ;
        odrl:target ex:PartA ;
        odrl:action odrl:present ;        
        odrl:assignee ex:Bob
    ] ;
    odrl:prohibition [
        a odrl:Prohibition ;
        odrl:target ex:PartB ;
        odrl:action odrl:present ;
        odrl:assignee ex:Alice 
    ] .
vroddon commented 7 years ago

However,

this is a valid policy, am I wrong?

inferred

ex:PartA odrl:hasPolicyhttp://example.com/policy:01 . ex:PartB odrl:hasPolicyhttp://example.com/policy:01 .

becomes invalid because not >all< rules of the policy have

both ex:PartA and ex:PartB as their target

http://example.com/policy:01 a odrl:Policy; odrl:assignee ex:Bob ; odrl:assignee ex:Alice ; odrl:permission [ a odrl:Permission ; odrl:target ex:PartA ; odrl:action odrl:present ] ; odrl:prohibition [ a odrl:Prohibition ; odrl:target ex:PartB ; odrl:action odrl:present ] .

Regards, Víctor

El 16/06/2017 a las 9:18, simon escribió:

3.4.3 Has Target Policy https://w3c.github.io/poe/vocab/#term-hasPolicy:

Note: The Asset being identified MUST be inferred to be the target
Asset of *all* of the Rules of the Policy.

+

Added: owl:inverseOf :target ;

+

Valid Policy:

http://example.com/policy:01 a odrl:Policy; odrl:permission [ a odrl:Permission ; odrl:target ex:PartA ; odrl:action odrl:present ; odrl:assignee ex:Bob ] ; odrl:prohibition [ a odrl:Prohibition ; odrl:target ex:PartB ; odrl:action odrl:present ; odrl:assignee ex:Alice ] .

=

Invalid Policy:

inferred

ex:PartA odrl:hasPolicyhttp://example.com/policy:01 . ex:PartB odrl:hasPolicyhttp://example.com/policy:01 .

becomes invalid because not >all< rules of the policy have

both ex:PartA and ex:PartB as their target

http://example.com/policy:01 a odrl:Policy; odrl:permission [ a odrl:Permission ; odrl:target ex:PartA ; odrl:action odrl:present ; odrl:assignee ex:Bob ] ; odrl:prohibition [ a odrl:Prohibition ; odrl:target ex:PartB ; odrl:action odrl:present ; odrl:assignee ex:Alice ] .

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c/poe/issues/184#issuecomment-308952898, or mute the thread https://github.com/notifications/unsubscribe-auth/AFLs5S04Zav5N3A-4K9db1DHyAyWIDEkks5sEixKgaJpZM4Nfl3j.

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

simonstey commented 7 years ago

not according to 3.4.3 Has Target Policy:

Note: The Asset being identified MUST be inferred to be the target Asset of all of the Rules of the Policy.

either you ignore the MUST -> policy becomes invalid

or you add the inferred target triples to the rules and end up with a new policy with different semantics

vroddon commented 7 years ago

In which sense is the word "inferred" used? If informally, I would say my expression is totally correct. If formally, it would not, unless we add this SWRL expression (what we do not want...):

assigner(?policy, ?X) ∧ permission(?policy,?P) ⇒ assigner(?P,?X)

simonstey commented 7 years ago

it was about assets :)

vroddon commented 7 years ago

Well, reformulated, I understand this is a valid policy. Am I wrong? Just to confirm....

<http://example.com/policy:01>
     a  odrl:Policy;
     odrl:assigner ex:Bob ;
     odrl:assignee ex:Alice ;
     odrl:target: ex:PartA ;
     odrl:permission odrl:present ;
     odrl:prohibition odrl:hide .

@simonstey I have edited the Turtle to make the most compact version that is possible. Alice can present but cannot hide PartA.

simonstey commented 7 years ago

well.. afaik not as you can't (and iirc never could) have actions as values for perm/proh.

vroddon commented 7 years ago

Disagree, this is the current ontology:

:permission
    a rdf:Property , owl:ObjectProperty, skos:Concept ;
    rdfs:isDefinedBy odrl: ;
    rdfs:label "Has Permission"@en ;
    skos:definition "Relates the description of an individual Permission to a Policy."@en ;
    skos:note "A permission can be specified either in terms of an Action alone, or an instance of Permission relating an Action and one or more other attributes."@en ;
    rdfs:domain :Policy ;
    rdfs:range [
        a owl:Class ;
        owl:unionOf ( :Permission :Action ) ;
    ] .
simonstey commented 7 years ago

which is then not in line with the current IM

vroddon commented 7 years ago

Oh! What a pity! Even the first example at the best practices doc uses that pattern, due to the extreme compacity, the absence of blanknodes and the ability to represent a policy as a collection of pairs property/value: a highly desired feature.

I have not found evidences on when this feature was agreed, nor when it was deprecated, so in order to be sure I want to ask aloud about this on Monday (maybe I did not check well the issues list or discussions in the minutes).

That line of the ontology was last edited by @riannella as per commit fdf4369 on July 2016, probably inherited from the ODRL2.1 spec (see https://www.w3.org/ns/odrl/2/ODRL21.ttl)

aisaac commented 7 years ago

I was asked by @riannella to check this one. Wrt to the original issue, there is still one issue pending: check the mappings from the new property odrl:hasPolicy to other DC and CCrel properties. And looking at @vroddon has done in this regard at https://www.w3.org/2016/poe/wiki/Best_Practices#3._How_to_grant_Alice_the_permission_to_use_an_asset_.28III.29 (though as of today, the RDF triples are still good to me! ) But I do not want to do this before the end of the very active and fresh discussion between @simonstey and @vroddon . Guys, can you ping me when you think you are finished?

riannella commented 7 years ago

Removed the "inverse" property.

commit: 034d59be9c7ac04c0318af5c79d084cc2a36f7d6

As for the turtle shortcut: odrl:permission odrl:present ;

We need to add this example to the "Policy Rule Composition" section.

simonstey commented 7 years ago

As for the turtle shortcut: odrl:permission odrl:present ;

We need to add this example to the "Policy Rule Composition" section.

I don't think we should allow this.. The benefits of being able to do something like this: 

<http://example.com/policy:01> 
    a odrl:Policy ;   
    odrl:permission odrl:present, odrl:archive, odrl:share .

instead of:

<http://example.com/policy:01> 
    a odrl:Policy ;   
    odrl:permission [
        a odrl:Permission ; # we could even allow to omit this
        odrl:action odrl:present, odrl:archive, odrl:share ;
    ] .

don't outweigh all the issues/complications this would come with..

(btw., that wouldn't be a turtle shortcut only.. all of that applies to any serialization of ODRL)

riannella commented 7 years ago

I am all for minimising "issues and complications" ;-) @vroddon ok?

vroddon commented 7 years ago

About allowing: <http://example.com/policy:01> odrl:permission odrl:present Pros:

Cons:

@simonstey Am I missing anything else? I would like this to hear more opinions, but indeed I am ok for "minimising issues and complications"

nitmws commented 7 years ago

We at IPTC have a rule for the syntax design: don't support expressing the same semantic assertion by syntax variants differently. The reason is quite simple: a parser has to check all syntax variants before statements can be retrieved from a document - and this makes parsers more complex and expensive. With that background I don't support such shortcuts - what is the real benefit? To have less characters in a policy document? This drove an IPTC team to create a standard in 2008 with "property names not longer than 12 characters" - today we say "that's history" and add properties with 20 characters.

vroddon commented 7 years ago

In such a case, I believe we can close this issue. I have effected the changes in commit ef769e80f70d529c186219cca3d8bfaaed5143a0

The range of :permission, :prohibition and :duty have been updated and consequently limited.

riannella commented 7 years ago

Reopening this - just from a process point-of-view - as this is an original "wide review" comment.

@aisaac are you ok with the resolution?

simonstey commented 7 years ago

@vroddon

About allowing: <http://example.com/policy:01> odrl:permission odrl:present Pros:

  • A policy can be described as a resource (policy01) with a set of properties and values.

well technically, the same holds true for: 

<http://example.com/policy:01> 
    a odrl:Policy ;   
    odrl:permission [
        a odrl:Permission ; 
        odrl:action odrl:present ;
        odrl:assignee ex:Bob ;
        odrl:target ex:Asset1 ;
    ] .

where <http://example.com/policy:01> is also a resource with properties and values ;)

... Ideal for lazy implementors, easy storage/processing (a policy as a POJO, stored in a single table in a relational database, or in a couple of columns in a CSV file).

  • Easy understandability, "less lines in a powerpoint": nobody will be able to say "I dont understand simple ODRL policies". Developers of the world happy.

There's an important difference between making policies "easy to understand" or "easy to store/process".

As outlined here and here 2.7 Policy Rule Composition, a user can write compact (thus easy to comprehend) policies, but in order to achieve interoperability an ODRL processor has to derive the policy's expanded/atomic form. If the same processor has to process a "normal" ODRL policy, it simply skips the expansion part, but is otherwise able to proceed as usual.

However, if you skip the expansion/transformation step and work with the compact representation only, you will indeed have "less lines in a ppt", but loose expressiveness and interoperability with "normal" policies.

@nitmws

We at IPTC have a rule for the syntax design: don't support expressing the same semantic assertion by syntax variants differently. The reason is quite simple: a parser has to check all syntax variants before statements can be retrieved from a document - and this makes parsers more complex and expensive. With that background I don't support such shortcuts - what is the real benefit?

What's your take on 2.7 Policy Rule Composition then? (btw. I agree with you on this)

aisaac commented 7 years ago

@riannella I am now quite unclear about what the 'resolution' is...

I see there is a hasPolicy from Asset to Policy, and dc:license is a subproperty of it. (btw the Turtle file apparently uses dct: and your documentation used dc:. Probably both should have the same) This seems to meet most of the original issue.

The only question mark is why odrl:hasPolicy owl:inverseOf :target has been removed.

The inverse axiom would certainly allow to infer correct statements for policies with direct attachement of targets as in example 24 at https://w3c.github.io/poe/model/

{ "@context": "http://www.w3.org/ns/odrl.jsonld", "@type": "Policy", "uid": "http://example.com/policy:8888", "target": "http://example.com/music/1999.mp3", [etc]

Then there is the issue of infering the hasPolicy links in the case when targets are attached to policies via rules. The owl:inverse wouldn't work if there is no direct link between the Policy and the target. But it could work if we add

odrl:target owl:propertyChainAxiom ( [ owl:unionOf ( odrl:permission odrl:prohibition ) ] odrl:target ) .

(this says that whenever there's a path policy-permission-target or policy-prohibition-target then one can infer a statement policy odrl:target target)

Of course this would require that this axiom is true, which is not clear. The "The processing model for Policies with multiple Assets, Parties, and Actions declared at the Policy-level" only propagates the target from a Policy to its attached Permissions or Prohibitions.

simonstey commented 7 years ago

(short answer for now)

Of course this would require that this axiom is true, which is not clear. The "The processing model for Policies with multiple Assets, Parties, and Actions declared at the Policy-level" only propagates the target from a Policy to its attached Permissions or Prohibitions.

it propagates it to all attached Perm/Proh.

which would together with ->

(this says that whenever there's a path policy-permission-target or policy-prohibition-target then one can infer a statement policy odrl:target target)

prevent policies from having rules with different targets.

aisaac commented 7 years ago

Alright, so the property chain axiom is irrelevant then, thanks for the answer.

This said I'm still curious about the inverse axiom. The definition for hasPolicy says: "Identifies an ODRL Policy for which the identified Asset is the target Asset to all the Rules.' and "The Asset being identified MUST be inferred to be the target Asset of all of the Rules of the Policy."

In the context of the the Processing Model that propagates a policy's target to all it's permissions and prohibitions, this seems quite compatible with odrl:hasPolicy owl:inverseOf odrl:target

nitmws commented 7 years ago

@simonstey my view on 2.7 Policy Rule Composition

First para (A Policy may contain ...) states "... each Rule may contain multiple Assets, Parties, Actions, Constraints, and Duties ..." but the Rule definition talks only about "an Action/Asset" vs "one or more Parties/Constraints". This lets me conclude: only a single Action or Asset is allowed, but multiple Parties and Constraints.

But the ODRL specification appears to be different: the section about "create the atomic Rules" (further down in this 2.7 section and hidden between examples) is based on the view "each Rule may contain multiple Assets, Parties, Actions, Constraints, and Duties". And it covers what @simonstey shows in the Policy Inference document.

This lower region of 2.7 also introduces Assets, Parties and Actions at the Policy level. These are shortcuts opening the expression of Asset(s), Party/ies and Actions of a Rule to two different ways. And the wording there is wrong: "This implies that these (Asset, Party, Action) classes are all common to all the Rules in the Policy,". No, they don't apply to any Duty Rule. As said above, shortcuts may save come characters but makes processing a Policy harder - and I hope all Policy Architects will be aware that an Action at the Policy level applies to both permissions and prohibitions, a potential source of conflict.

These shortcuts may raise confusion as also Constraints may occur at the Policy level - but they do NOT apply to all Permission/Prohibitions of a Policy. In fact these Constraints are no shortcuts - what makes a distinction?

The second para of 2.7 reminds of issue of #173: what is the "core" of ODRL? The IM Introduction says "The information model covers the core concepts, entities and relationships that provide the foundational model for content usage statements." My conclusion: each word in the Information Model is about the core ODRL except words in non-normative sections - oops, the Introduction is non-normative. Finally the second para tells: "This example shows the atomic level of a Policy where it is an irreducible Rule (that is, not able to be reduced or further simplified)". Based on what definitions or rules has Example 21 been formulated? Or is Example 21 the rule?

riannella commented 7 years ago

@aisaac

In the context of the the Processing Model that propagates a policy's target to all it's permissions and prohibitions, this seems quite compatible with odrl:hasPolicy owl:inverseOf odrl:target

But it does not work the other way...if you have a Policy with two Permissions each with a different target Asset. The inverse will mean that each target Asset is a target to the entire Policy.

riannella commented 7 years ago

With Duties now becoming part of the Policy-level Rules #162 we need to revisit the "Policy Rule Composition" narrative...

simonstey commented 7 years ago

But it does not work the other way...if you have a Policy with two Permissions each with a different target Asset. The inverse will mean that each target Asset is a target to the entire Policy.

with odrl:hasPolicy owl:inverseOf odrl:target and given following policy:

<http://example.com/policy:01> 
    a odrl:Policy ;   
    odrl:permission [
        a odrl:Permission ; 
        odrl:action odrl:present ;
        odrl:target ex:Asset1 ;
    ] ;
    odrl:prohibition [
        a odrl:Prohibition ; 
        odrl:action odrl:share ;
        odrl:target ex:Asset2 ;
    ] ;

a reasoner would infer:

ex:Asset1 odrl:hasPolicy _:bPerm .
ex:Asset2 odrl:hasPolicy _:bProhib .
riannella commented 7 years ago

wouldn't it infer:

ex:Asset1 odrl:hasPolicy <http://example.com/policy:01> .
ex:Asset2 odrl:hasPolicy <http://example.com/policy:01> .
simonstey commented 7 years ago

wouldn't it infer:

ex:Asset1 odrl:hasPolicy <http://example.com/policy:01> .
ex:Asset2 odrl:hasPolicy <http://example.com/policy:01> .

no, because in:

<http://example.com/policy:01> 
    a odrl:Policy ;   
    odrl:permission [
        a odrl:Permission ; 
        odrl:action odrl:present ;
        odrl:target ex:Asset1 ;
    ] ;
    odrl:prohibition [
        a odrl:Prohibition ; 
        odrl:action odrl:share ;
        odrl:target ex:Asset2 ;
    ] ;

the subjects of the two odrl:target triples are the two Rule blank nodes:

<http://example.com/policy:01> a odrl:Policy .

<http://example.com/policy:01> odrl:permission _:bPerm .
_:bPerm a odrl:Permission .
_:bPerm odrl:action odrl:present .
_:bPerm odrl:target ex:Asset1 .
ex:Asset1 odrl:hasPolicy _:bPerm . # inferred

<http://example.com/policy:01> odrl:prohibition _:bProh .
_:bProh a odrl:Prohibition .
_:bProh odrl:action odrl:share .
_:bProh odrl:target ex:Asset2 .
ex:Asset2 odrl:hasPolicy _:bProh . # inferred
riannella commented 7 years ago

Ok, so I removed the inverseOf axiom as I thought from here: https://github.com/w3c/poe/issues/184#issuecomment-308952898 That it was not correct?

simonstey commented 7 years ago

Ok, so I removed the inverseOf axiom as I thought from here:

184 (comment)

That it was not correct?

aah.. yes my bad.. it's still not correct though, because it would then point to a Rule instead of a Policy.

riannella commented 7 years ago

Ok, just to be clear, we don't add the inverseOf axioms.

simonstey commented 7 years ago

Ok, just to be clear, we don't add the inverseOf axioms.

👍

aisaac commented 7 years ago

Hi everyone,

Every time I look at this issue I can't prevent from thinking about semantics, and that I need a lot of time to think about them here...

So I still agree with not having [ odrl:hasPolicy owl:inverseOf odrl:target ] But I'm still puzzled about the absence of any formal semantics, especially when I read "Identifies an ODRL Policy for which the identified Asset is the target Asset to all the Rules.".

I've tried to find a way to make a property chain axiom work, as I had suggested above. Or an use a sort of limited inverse axiom (i.e. when odrl:target is only used with odrl:Policy as subject). But while I gave another try today, I was not successful so I'm going to declare I'm done with the issue for now!

aisaac commented 7 years ago

And another, small comment: If in the future the example from @vroddon at https://www.w3.org/2016/poe/wiki/Best_Practices#3._How_to_grant_Alice_the_permission_to_use_an_asset_.28III.29 is still going to be used (which I hope it will!), it would be useful to add a note like indicating that dct:license is a sub-property of odrl:hasPolicy, and therefore the statements in the example imply the statement [ http://example.com/asset/1 odrl:hasPolicy http://example.org/policy/1 ] which makes the example fully compatible with the core of ODRL.