Vocab clarifications

[riannella]

@aisaac

• I think it is not really helpful to have two different Actions vocabularies (one for P/O and the other one for Duties). This sort of ontological commitment can even be dangerous. Why can’t an action now earmarked for P/Os, say Distribute, be used as a Duty? One could imagine that a Party gets the permission to do things with an Asset, on the basis that this party takes care of distributing it. A bit like the copyright agreement between researchers and journal publishers, where the latter commit to employ their distribution network to promote the publish papers.
  In fact, while the wording of Action definitions is very much focused on this division (e.g. “The Assigner permits/prohibits the Assignees to distribute the Asset.” at https://www.w3.org/TR/odrl-vocab/#term-distribute) it is not enforced in the vocabulary by creating two distinct OWL ontologies or SKOS concept schemes. It is also not motivated (and maybe not even mentioned?) in the Information Model at https://w3c.github.io/poe/model/#action. My recommendation would be to remove any hint of this distinction from the Vocabulary document (structure of sections, wording of definitions, and separate Action boxes in figure 1)

• often, the relation between POE and SKOS, wrt. the notions of ‘concepts’ and ‘vocabularies’, was not clear to me. Section 4 present a number of ‘vocabularies of applicable terms’. Some of them consist of instances of skos:Concept, some of them of instances of owl:Thing, some of them extend/refine existing POE classes by sub-classing (e.g., the Policy Types). Also, others are mentioned as concepts (Rule at https://www.w3.org/TR/odrl-vocab/#term-Rule) but they’re not defined as such. Are all these different ways necessary? Is typing anything as an owl:Thing any helpful actually?
  Further, when looking at the ODRL Turtle serialization, I see instances of skos:Concept (:use), instances of skos:ConceptScheme (:actions), but no skos:inScheme statement to relate them. Some groupings of concepts are defined as skos:Collection, while there could be defined as (small) ConceptScheme, like http://www.w3.org/ns/odrl/2/#policyTypes .
  Perhaps a general examination of all this is desirable. Especially if concept schemes could play a bigger role in the future (see my comment about adapting for POE the approach of Web Annotation for extending its default sets of concepts, in https://lists.w3.org/Archives/Public/public-poe-comments/2017Apr/0007.html). NB: the extension pattern used by WA is applicable to OWL classes like Policy type, so I think keeping ‘vocabularies’ of subclasses of existing POE classes is ok, it’s just that they should probably be flagged as different kind of vocabularies to clarify the situation.
  Finally the Turtle serialization uses skos:broaderTransitive for cases where skos:broader should probably be used. See https://www.w3.org/TR/skos-primer/#sectransitivebroader “one can interpret skos:broader statements as explicitly asserted direct parent links, while skos:broaderTransitive is used to reflect more-general (and possibly indirect) ancestor relationships.”

• 4.1.1 target, assigner, assignee aren’t among the properties for Policy? And (as one example), in 4.8.1 odrl:target is mentioned to have only Rule as domain? The POE information model mentions that these can appear at the Policy level (https://www.w3.org/TR/odrl-model/#composition, for example, example 6)

• about odrl:relation: in the end, is it worth having an abstract property when it has only two concrete sub-properties (odrl:output and odrl:target)? And when it has such an abstract name - and which conflicts with many general properties with similar names but an actually more generic meaning, like rdfs:property and dc:relation.

• 4.9.3 All, All2ndConnections, AllConnections and AllGroups are not defined in the information model. Then I realized that the information model itself in 3.3.2 (https://www.w3.org/TR/odrl-model/#party-scope) is quite strange. It says “The scope attribute SHOULD take one of the following values: [individual and group]” and then “Other URI values for the scope attribute SHOULD be defined in the ODRL vocabulary [vocab-odrl] and ODRL Profiles.”, which is a bit contradictory.

• what’s the difference between odrl:All and odrl:Group?

• it seems that the various types of scopes could be arranged as a SKOS concept scheme, with skos:broader links between e.g. odrl:All2ndConnections and odrl:Group. This would better reflect your notices ‘Note that “group” scope is also assumed’.

[vroddon]

This is a bunch of issues.

1. Actions for Duties, actions for Permissions/Obligations. I agree with Antoine, as I don't find a reason to split the actions in two categories. But I think this deserves discussion.
2. SKOS - I have no opinion about what to do. What should we implement?
3. I don't see anything wrong in Section 4.1.1. However, I see Section "3.1.1 Policy Composition" in the model as something wrong. @sereAbi What do you think about example 3 and example 4? I think you can correct them
4. Removing odrl:relation: I totally agree, with no more argument than simplicity. Does this need WG discussion?
5. Scope of party. What shall we do? I don't see Antoine's problem.
6. group/all i don't see Antoine's problem, all is "all", and group is "several".

[nitmws]

re use of SKOS
My background: I'm maintaining the about 200 IPTC controlled vocabularies = concept schemes and IPTC has adopted SKOS. From that point of view:

The ODRL ontology used both skos:Collection-s and skos:ConceptsScheme-s. I have to say frankly it is hard to make a clear distinction between both, From their definitions l infer collections are closer to what an enumeration is in the programming context (a list of terms dedicated to a very specific use) and the concept scheme is a container of concepts - they may be used for specific purposes, but they don't have to.

Actions by the WG:

• It would be great if POE/ODRL could define for what purposes skos:Collection and skos:ConceptScheme should be used.
• And: I'm not aware of any limitation of having a Concept only in a skos:Collection or skos:ConceptScheme - I think all Concepts should be contained by an ODRL Concept Scheme - and ODRL my have some.
• ODRL defines a single skosConceptScheme "actions" and claims in free text that many actions - from anonymize to compensate - are included. But there not a single skos:inScheme - which is the corresponding definition by SKOS. And using skos:isTopConcept/skos:hasTopConcept is also of great help to clarify the hierarchy. (This was already pointed at by Antoine)

[aisaac]

Some extra comments: 2. (SKOS) The idea would be to homogeneize all the concept-like resources of POE are represented, solving the issues noted by @nitmws and I, articulating with the suggestion to use SKOS to handle extensions/profiles in #160 @nitmws: about skos:ConceptScheme vs skos:Collection, I think in general POE doesn't have anything that should be represented as skos:Collection Gathering concepts (whether actions or other types of resources) into ConceptSchemes should be good enough. 3. (policy properties) @vroddon the issues I have with 4.1.1 is that the description of Policy doesn't include all properties that can be applied to instances of this class, which should appear in "Properties:" 5. (scopes) The issue here is that the vocabulary introduces resources that are not defined in the Information Model. Section 3.3.2 in the old IM (https://www.w3.org/TR/2017/WD-odrl-model-20170223/#asset-scope) said that "The scope attribute SHOULD take one of the following values: individual [...] group". The new IM is better because it replaces the SHOULD by a MAY. And the sentent "Other scope property IRI values SHOULD be defined in the ODRL Vocabulary [vocab-odrl] " in the IM but this is quite moot. As the vocabulary is given, IRIs exist there or they do not, it's not a matter of SHOULD. And if they are I don't see why they wouldn't have been introduced in the IM. But this is probably rather an issue for the IM now! 6. ("all" and "group" scopes). You say 'all is "all", and group is "several"'. This may be fine, but it wasn't and still is not that clear in the Vocabulary doc http://w3c.github.io/poe/vocab/#term-Group http://w3c.github.io/poe/vocab/#term-All Nor in the IM model (if just because the IM doesn't define All, as pointed in 5). Actually as of today the IM at https://w3c.github.io/poe/model/#party-scope reads "The linked Permission, Duty or Prohibition is applicable to each member of that group. For example, a Permission to play a movie 5 times is valid for every Party member", which contradicts your 'all is "all", and group is "several"'. In fact the latter sentence is also inconsistent with the Vocab doc saying 'Note that “group” scope is also assumed’ for All.

…

On 14/05/17 10:51, Michael Steidl wrote: re uses of SKOS My background: I'm maintaining the about 200 IPTC controlled vocabularies = concept schemes and IPTC has adopted SKOS. From that point of view: The ODRL ontology used both skos:Collection-s and skos:ConceptsScheme-s. I have to say frankly it is hard to make a clear distinction between both, I feel collections are closer to what an enumeration is in the programming context (a list of terms dedicated to a very specific use) and the concept scheme is a container of concepts - they may be used for specific purposes, but they don't have to. Actions by the WG: * It would be great if POE/ODRL could define for what purposes skos:Collection and skos:ConceptScheme should be used. * And: I'm not aware of any limitation of having a Concept only in a skos:Collection or skos:ConceptScheme - I think all Concepts should be contained by an ODRL Concept Scheme - and ODRL my have some. * ODRL defines a single skosConceptScheme "actions" and claims in free text that many actions - from anonymize to compensate - are included. But there not a single skos:inScheme - which is the corresponding definition by SKOS. And using skos:isTopConcept/skos:hasTopConcept is also of great help to clarify the hierarchy. (This was already pointed at by Antoine) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#164 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAnprXmWsuOEkQ-quKRgVinrun88feW7ks5r5sB7gaJpZM4NNsHV>.

[riannella]

OK, lots of stuff here ;-)

1. Actions - difference between P/O and Duties.
   Ok - we will put all actions in one section "Actions for Rules"

2. SKOS

• I know we primarily use skos:Collection to drive the script to create the Vocab sections in the document.
• We will change from using skos:broaderTransitive to odrl:narrowerThan (as there are more semantics here that just representing a KOS hierarchy)
• I have no view on the use of skos:Concept. If there are others terms in the ontology we should add, then please suggest.

3. Missing properties.
   Yes, I think I have found a small bug in our script - It seems ok for single Ranges, but not UnionOf....will fix @nevali ;-)

4. odrl:relation - the reason is that other communities - thru Profiles - may define subtypes (the fact that we can only think of two...should not mean we remove the abstract parent...and it can also be used to query for any type of relation between Rule and Asset)

5. Scopes
   All the scopes are gone (including deprecated 2ndConnections etc..)

[aisaac]

1 -> sounds good to me! 3 -> ok I trust this will be fixed, I won't check it! 4 -> ok I see the point now, and the mention of the sub-property pattern in your last ED http://w3c.github.io/poe/model/#profile-requirements I see this extension pattern is even mentioned in http://w3c.github.io/poe/model/#relation which is very useful. 5, 6 -> I think I will have a problem with the new pattern for constraints on assets and parties, if there's still the same "URI-hijacking" that I dislike in #162. But that's probably to be discussed in #162 or another issue, not in the ticket here. At least the new approach with constraints look less confusing about its semantics than the scope one! 2. I would like to carry on a full analysis of the ODRL/SKOS analysis and give you an answer. But this is pending the question on the semantics of the new constructs you've introduced in the context of #160. Maybe we should open a new ticket and include all the SKOS matters and then close this one?

[riannella]

5/6 - We added the new AssetCollection and PartyCollection classes to address URI-hijacking.
This means the URI for an Asset/PartyCollection identifies a group of resources/entities that the constraint is applied to (constraints cannot be applied to an Asset or Party class).

2 - Can you add to #160 ?

[riannella]

1. Moved all Actions into one section (Actions for Rules)

commit 30fd9e6

[aisaac]

OK I've added a note in #160 about the SKOS matters here. so the last item to discuss here (or is it elsewhere too, I may revisit this comment if I find it elsewhere) is the problem of URI-hijacking for parties and assets. Creating new classes doesn't solve the issue. It's about which resource (id/uid) are created or re-used. Their type doesn't matter much. As of now, the issue is still present, e.g., in example 19 in 2.64 at https://w3c.github.io/poe/model/#constraint-party.

[riannella]

Are you proposing that instead of the constraint mechanism for parties/assets, we should (more simply) say that you mint a new URI?

So in example 19, the assignee is "http://example.com/user44/friends/age/gt/17" ?

[aisaac]

I am proposing that for the assignee (or any resource that results from the application of constraints) one shouldn't re-use a URI that already has a a different meaning. So either minting a new URI or leaving the assignee anonymous (by leaving it as a blank node). In any case I am not proposing this instead of the stating the constraints. These are needed for expressing the information. From a machine perspective, these URIs should indeed be considered to be opaque. Is this clearer? Btw I am surprised that there is no one in the group that would share the same concern or help us make progress here. It seems like a discussion between the two of us. I mean, we're progressing, but I'm surprised that no one with a Semantic Web background has ever reacted to the matter. I don't feel I'm standing on a super-exotic standpoint. Or am I?

[riannella]

The uid has moved to a "Should" now.

So, this is possible:

   odrl:assigner [ 
        a odrl:Party ;
        foaf:name "Bob" ;
    ]

See #174

[aisaac]

This is a very good move forward! Still I would insist that there should be nothing in the spec that encourages people to hijack URIs, which is a bad practice. It's not only about letting users the opportunity to do things in an ok way, it's about discouraging them to do bad things. But I guess we were almost already there when in your previous comment you suggested that in example 19, the assignee is "http://example.com/user44/friends/age/gt/17". This was good, sorry I didn't react on this. I was in a hurry as the first part of your comment was hinting that I was advocating throwing the baby (constraint mechanism) with the bathwater (hijacking URIs), which was not the case :-)

…

On 19/06/17 05:52, Renato Iannella wrote: The uid has moved to a "Should" now. So, this is possible: |odrl:assigner [ a odrl:Party ; foaf:name "Bob" ; ] | See #174 <#174> — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#164 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAnprYvTuO4Go_-94A0_V5TWK5a5WhCQks5sFfCCgaJpZM4NNsHV>.

[riannella]

Ok, I've added a sentence to the narrative (to hopefully) capture that.

commit: 5ee91db

[aisaac]

I'm sorry it's still not solving the problem. It's not really about what is meant with the pattern, it's what is asserted in RDF. Basically as long as example 20 remains with the hijacking of the 'friends of user 44' URI as it is currently at https://github.com/w3c/poe/blob/5ee91db6a45a41b4e7dea0f7aa35b33f6c8aebc2/model/index.html then the issue I've raised in point 7 at #162 (comment) still applies. I.e. stating the constraint applies to http://example.com/user44/friends means that for any client that has read this statement it will apply to any occurrence of http://example.com/user44/friends, even withing a rule would use this group in a different constraint (say, one that would select children friends of user 44). This is what is done by using the "uid" attribute. And this is why I was interested in the Web Annotation pattern for selectors at https://www.w3.org/TR/annotation-model/#selectors With that pattern, http://example.com/user44/friends would appear in a "source" attribute, not "uid". And in RDF terms this makes a *huge* difference.

[riannella]

Ok, I am slowing being to understand :-))

So, if for PartyCollections (and also AssetCollection) we also had a "source" property, and we stated that you must use this if you want to use a constraint, such as:

 "assignee": {
            "@type": "PartyCollection",
            "source":  "http://example.com/user44/friends",
            "constraint": [{
                "leftOperand": "foaf:age",
                "operator": "gt",
                "rightOperand": "17"
            }],

Then that would be ok?

[aisaac]

Yes, "source" as is used in your last example would be good! Or "base", or whatever the group prefers. Since you are creating your own pattern, not re-using the Web Annotation one, you are rather free. The condition is that the property allows to put some 'distance' between the original (group of) entities and the party that is derived from it.

[riannella]

Ok, will raise at Monday's teleconf

[riannella]

WG agreed to this (26 June)

[riannella]

Added the source property

commit 68fdba3

[aisaac]

This looks fine! I just have one doubt: I had not realized that this pattern was for constraints that applies to groups (collections) of resources. I thought it could be a bid wider, as in the Web Annotation pattern for SpecialResource. If source applies to collection, then its meaning may be compared to a part-of relationship, like dc:isPartOf. I mean, the new resource (sub-collection) is a part of the original one. So maybe you could re-use dc:isPartOf directly. But that may have unintended consequence though, as it probably doesn't carry a meaning as precise as what you seek for collection constraints (I mean, "source" points to the set use as base for extracting the group of interest, it's not any super-set). So a more conservative stance could be to add a sub-property axiom between odrl:source and dc:isPartOf. I won't push it very hard, because it is clearly not crucial to the model. But it may bring some useful interoperability later on. And for now, clarify the intended semantics of odrl:source.

[riannella]

Thanks @aisaac - closing this issue