Re: About a more strict definition of Constraint

Thank you, now I understand.

Looking at the smallest possible changes… in any case, the issue seems to be that the constrained object (more exactly its URL) must be explicitly expressed. I see, at this point, two possibilities (both work, probably):

1. your approach, described in, which would 'open up', via an extra blank node, the object resource of odrl:target and friends, adding an extra property to denote the real 'target'
2. Some sort of approach like Michael's

On #1:
I am little bit worried about your approach insofar as
- either it would be required to always 'open' up odrl:target, ie, always use a blank node as an object; or
- the object can be a URL or a blank node, the latter in the case there is a constraint assigned

which would make, say, any formal processing or check a bit more complicated.

On #2:
I would avoid even giving the impression that we are talking about triples, reification, etc; that would raise too much questions. Isn't possible to formulate it by saying that we introduce two odrl properties, both to be used on a Constraint class, namely (I just make up the names):

- odrl:constrainedObject: its value is a URL and refers to the object being constrained
- odrl:constrainedRole: refers to whether the constrained object is a target, an assigner, and assignee, or another constraint (!)

and the rest of the Constraint class remains unchanged. I believe this is close to Michael's version, but there is no discussion about any new RDF triples, implicit or explicit.

(I do not know if any of these two can be made optional.)

I have, at this point, somewhat more sympathy to #2, but that may just be a temporary feeling…

I am not sure I could help…

Cheers

Ivan




> On 11 Nov 2016, at 00:42, Renato Iannella <renato.iannella@monegraph.com> wrote:
> 
> 
>> On 10 Nov. 2016, at 15:42, Ivan Herman <ivan@w3.org <mailto:ivan@w3.org>> wrote:
>> 
>> If the former, I would like to understand what the problem is with what you have there, ie, that an individual of a Constraint class is the object of the odrl:contraint predicate, whose subject is pretty much what you need.
> 
> Ivan, the problem is shown below:
> 
>  odrl:permission [
>     a odrl:Permission ;
>     odrl:target <http://example.com/music:4545 <http://example.com/music:4545>> ;
>     odrl:assigner <http://example.com/sony:10 <http://example.com/sony:10>> ;
>     odrl:assignee <http://example.com/sony:10 <http://example.com/sony:10>> ;
>     odrl:action odrl:copy ;
>     odrl:constraint [ …#1... ] ;
>     odrl:constraint [ …#2... ] ;
>     odrl:constraint [ …#3... ]
>   ] .
> 
> The current processing rule is that constraint #1-3 all apply to the Action.
> 
> But I want to apply Constraint#1 to the Action, #2 to the Asset, and #3 to the Assignee ?
> 
> Renato Iannella, Monegraph
> Co-Chair, W3C Permissions & Obligations Expression (POE) Working Group
> 


----
Ivan Herman, W3C
Digital Publishing Technical Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
ORCID ID: http://orcid.org/0000-0003-0782-2704