Re: [poe] Model clarifications

1. OK

2. OK

3. OK

4. I am not sure the commit addresses my point. "Policy Composition" is still the heading of (the new) section 3.7. May complain is that this expression is ambiguous. On the one hand, it can be understood as discussing the contents/components of a Policy. But one could also understand it as an attempt to compose different Policies together, which is not the case. (In a way, the new first sentence "A Policy MAY contain multiple Rules [...]" is much clearer about the scope of the section)

5. I see that Issue #138 did not lead to any major change, so I suppose my comment still applies?
In any case I don't see why *not* restricting conflicts to only Permissions and Prohibitions would harm POE. The restrictions on permissions and prohibitions seems like a case of ontological commitment that brings little added value.

6. OK

7. The new text clarifies the intention behind scopes and their use case.

I now have to flag them as a case of very bad RDF practice of 'hijacking' identifiers. Namely, I expect http://example.com/media-catalogue to be the identifier of the full catalogue. It is quite absurd to state that this uid is both the identifier of the full catalogue and the identifer of the 'scoped' part of itself. You say that this is motivated by the fact that the part of the cataloguer. This is a valid requirement, but no reason to abuse the original identifer. In fact it should not be 'uid' that is used to refer to the full catalogue, but some other property. Which is why was suggesting to look at the selector pattern in Web Annotation, which can meet your original requirement in a much harmless way.

I have a similar reaction to the example in 3.3.2. It is quite absurd to imagine that a Party that "is a single individual" or "represents a group of individual members" could be anything else. This is not really a job for scoping the meaning of a resource, but typing it, truly. Why not having used @type?

Actually the example with the party allows me to show the absurd side effect of the current pattern.
Imagine a Policy that targets the sub-group of user44's friends that are over 18. The representation of this Policy will include the following, as in example 8:
{
    "uid": "http://example.com/user44/friends",
    "scope": [ "Group", "http://example.com/people/age/18+"] 
}

Imagine that at the same time there is another Policy that targets the sub-group of user44's friends that are below 18. I suppose that this will lead to a representation including something like
{
     "uid": "http://example.com/user44/friends",
     "scope": [ "Group", "http://example.com/people/age/18-"] 
}

Now if one loads the representation of these two policies in an RDF store, this will lead to the following description for the group of friends of user44
{
     "uid": "http://example.com/user44/friends",
     "scope": [ "Group", "http://example.com/people/age/18+", "http://example.com/people/age/18-"] 
}

Am I wrong? If not, then what does this mean? Note that this wouldn't be fancy inference, just the application of what the RDF data model is. It is bad to hijack identifiers to represent something that they are not really meant to represent.

Btw 3.3.2 has a typo "The scope feature is useful is there is no ability to directly identify the intended Party with a uid identifier"

8/9. OK

10. OK

11. About https://www.iso.org/obp/ui/#iso:code:3166:IT: using what looks like a URI for a value that didn't have to be de-referenced is really quite unfortunate!
Also, I still don't understand the rationale for rightOperandReference. This is for the cases where the value is a URI that will be de-referenced?
In this case:
- it could be alright to have rightOperand used both with literal values and URIs. My comment here has not been answered
- I really don't get that "dataType indicates the type of the rightOperand/Reference, such as xsd:decimal or xsd:datetime" as is written in the new 3.6.1. If it's a URI, then it's not really expected to have a dataType like xsd:decimal or xsd:datetime
I guess examples may clarify whether I'm completely misunderstanding what happens here, or there is something really fishy with rightOperandReference

And in fact now that I read these sentences and example with datatypes I'm puzzled even with the use of datatypes with rightOperand. I'm not sure why POE introduces its own dataType property and does not re-use one of the options for data types in JSON-LD at https://www.w3.org/TR/json-ld/#typed-values


12. I really like the new examples, they really put the interest of inheritance clear!
There's just a typo on 'assinger' and the sentence "and allows the archive and annotate Permissions and the aggregate Prohibition." is strange (one would 'allow a Prohibition'?)


On 05/05/17 05:18, Renato Iannella wrote:
> We have made a major update to the IM that addresses many of these comments now.
>
> See this commit e055b79 <https://github.com/w3c/poe/commit/e055b79b52922eb52942a7622cebe25df3c091f1>
>
> 1 - covered in commit
>
> 2 - removed all the "refers"
>
> 3/4 - covered in commit
>
> 5 - The ODRL conflict strategy only deals with perms/prohit conflicts. We have issue #138 <https://github.com/w3c/poe/issues/138> discussing this now.
>
> 6 - Added more details.
>
> 7 - Updated the two scope sections. One reason for this feature is that there may not be the ability to identify the scoped-group with a URI.
>
> 8/9 - covered in commit
>
> 10 - Done
>
> 11 - Updated the text. That example is a not rightOperandReference, it is that actual URI that is compared to the leftOperand. That is, you do not deref the "IT" uri to get the value.
>
> 12 - Updated the use case examples
>
> New commits 3a11111 <https://github.com/w3c/poe/commit/3a11111d80d6db29d13a10e88d99aff6346ca1cf>
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub <https://github.com/w3c/poe/issues/162#issuecomment-299361282>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAnprTap1dNVLKpo9VGs-IqO9wRqhKeeks5r2pUUgaJpZM4NNsA->.
>


-- 
GitHub Notification of comment by aisaac
Please view or discuss this issue at https://github.com/w3c/poe/issues/162#issuecomment-302255515 using your GitHub account

Received on Wednesday, 17 May 2017 23:04:58 UTC