- From: Ivan Herman <ivan@w3.org>
- Date: Tue, 8 Nov 2016 15:47:26 +0100
- To: Michael Steidl <mdirector@iptc.org>
- Cc: W3C POE WG <public-poe-wg@w3.org>
- Message-Id: <8655BCAA-45AD-451E-8E7C-21E6416D52E6@w3.org>
Michael,
thank you.
Putting my (expired…) RDF expert's hat on, I have two problems with what you propose.
1. It makes even the simple cases more complicated; this may solve the issue of constraint on constraints, but the price we pay may be high, see below (I am not sure what the percentage of constraint on constraint usage is)
2. What you do is, in fact, a reification. This may have to be done, so I do not say that as some sort of a bug, but we have to realize that this is what we are talking about. It has the same problem as RDF reification: if I take, for example, your version of ex. 8:
odrl:constraint [
a odrl:Constraint ;
odrl:constraintsubject odrl:action;
odrl:constraintterm odrl:count;
odrl:operator odrl:lteq;
odrl:rightoperandvalue 1
I believe what you do talk about is the triple
odrl:action odrl:count [
odrl:operator odrl:lteq;
odr:rightooerandvalue 1
]
(or something like that). However, that triple and blank node combination is not asserted in the RDF graph. It has to be asserted/derived by a separate, ODRL specific processor, essentially using a specific rule to expand the graph. This can of course be added to the processing model/semantics of ODRL, but it strikes me as being fairly complicated...
Ivan
> On 8 Nov 2016, at 12:54, Michael Steidl (IPTC) <mdirector@iptc.org> wrote:
>
> Hi Ivan – and all,
> ok, let’s have a look at the Examples https://www.w3.org/TR/vocab-odrl/#examples <https://www.w3.org/TR/vocab-odrl/#examples> with constraints.
>
> I’ve modified snippets of the Turtle syntax, changes are highlighted.
> The major changes for turning a constraint into an explicit RDF triple:
> - Each constraint has an explicit odrl:constraintsubject = subject of the triple
> - Each constraint has an explicit odrl:constraintterm = predicate of the triple
> - Odrl:operator, odrl:rightoperandvalue, odrl:rightoperanddatatype, odrl:rightoperandunit make jointly the object of the triple
>
> See my Open Issues section below the examples.
>
> * 6.2 offer / Example 8
> <http://example.com/policy:0231 <http://example.com/policy:0231>>
> a odrl:Offer ;
> 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:action odrl:play ;
> odrl:duty _:requirements
> ] ;
> 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:action odrl:copy ;
> odrl:duty _:requirements ;
> odrl:constraint [
> a odrl:Constraint ;
> odrl:constraintsubject odrl:action;
> odrl:constraintterm odrl:count;
> odrl:operator odrl:lteq;
> odrl:rightoperandvalue 1
> ]
> ] .
> Human language variant of the triple:
> “the action of this permission” “has Count constraint” “lower than or equal – 1”
>
> * 6.3 agreement – same as above
>
> * 6.5 ticket / Example 20
>
> <http: <http://example.com/policy:0811>// <http://example.com/policy:0811>example.com <http://example.com/policy:0811>/ <http://example.com/policy:0811>policy:0811 <http://example.com/policy:0811>>
> a odrl:Ticket ;
> odrl:permission [
> a odrl:Permission ;
> odrl:action odrl:play ;
> odrl:target <http: <http://example.com/game:4589>// <http://example.com/game:4589>example.com <http://example.com/game:4589>/ <http://example.com/game:4589>game:4589 <http://example.com/game:4589>> ;
> odrl:constraint [
> a odrl:Constraint ;
> odrl:constraintsubject odrl:action;
> odrl:constraintterm odrl:validTo; {note: new term}
> odrl:operator odrl:lteq ;
> odrl:rightoperandvalue "2010-12-31"^^xsd:date
> ]
> ] .
> Human language variant of the triple:
> “the action of this permission” “has Valid To constraint” “lower than or equal – 31 December 2010 (of type date)”
>
> * 6.6 Offer and next policy / Example 24 <>
>
> <http: <http://example.com/policy:5531>//example.com/policy:5531 <http://example.com/policy:5531>>
> a odrl:Offer ;
> odrl:permission [
> a odrl:Permission ;
> odrl:action odrl:distribute ;
> odrl:target <http: <http://example.com/wallpaper:2321>//example.com/wallpaper:2321 <http://example.com/wallpaper:2321>> ;
> odrl:assigner <http: <http://example.com/sony:99>//example.com/sony:99 <http://example.com/sony:99>> ;
> odrl:constraint [
> a odrl:Constraint ;
> odrl:constraintsubject odrl:action;
> odrl:constraintterm odrl:spatial;
> odrl:operator odrl:eq ;
> odrl:rightoperandvalue <http: <http://ontologi.es/place/IT>//ontologi.es/place/IT <http://ontologi.es/place/IT>>
> ] ;
> odrl:duty <http: <http://example.com/duty:01>//example.com/duty:01 <http://example.com/duty:01>>, <http://example.com/duty:02 <http://example.com/duty:02>>
> ] .
> Human language variant of the triple:
> “the action of this permission” “has Spatial constraint” “equal – a place with the id http://ontologi.es/place/IT <http://ontologi.es/place/IT>”
>
> <http: <http://example.com/duty:01>//example.com/duty:01 <http://example.com/duty:01>>
> a odrl:Duty ;
> odrl:action odrl:pay ;
> odrl:constraint [
> a odrl:Constraint ;
> odrl:constraintsubject <http: <http://example.com/duty:01>//example.com/duty:01 <http://example.com/duty:01>>;
> odrl:constraintterm odrl:payAmount;
> odrl:operator odrl:eq ;
> odrl:rightoperandvalue 1000.00 ;
> odrl:rightoperandunit <http: <http://cvx.iptc.org/iso4217a:EUR>//cvx.iptc.org/iso4217a:EUR <http://cvx.iptc.org/iso4217a:EUR>>
> ] .
> Human language variant of the triple:
> “the thing with the id http://example.com/duty:01 <http://example.com/duty:01>” “has Pay Amount constraint” “equal – 1000.00 units of the currency EUR”
>
> * 6.7 Privacy policy / Example 28
>
> <http: <http://example.com/policy:1111>// <http://example.com/policy:1111>example.com <http://example.com/policy:1111>/ <http://example.com/policy:1111>policy:1111 <http://example.com/policy:1111>>
> a odrl:Privacy ;
> odrl:permission [
> a odrl:Permission ;
> odrl:action odrl:distribute ;
> odrl:target <http: <http://example.com/billie:888:personal-data>// <http://example.com/billie:888:personal-data>example.com <http://example.com/billie:888:personal-data>/ <http://example.com/billie:888:personal-data>billie:888:personal-data <http://example.com/billie:888:personal-data>> ;
> odrl:assigner <http: <http://example.com/billie:888>// <http://example.com/billie:888>example.com <http://example.com/billie:888>/ <http://example.com/billie:888>billie:888 <http://example.com/billie:888>> ;
> odrl:assignee <http: <http://example.com/gov:health:au>// <http://example.com/gov:health:au>example.com <http://example.com/gov:health:au>/ <http://example.com/gov:health:au>gov:health:au <http://example.com/gov:health:au>> ;
> odrl:duty [
> a odrl:Duty ;
> odrl:action odrl:delete ;
> odrl:constraint [
> a odrl:Constraint ;
> odrl:constraintsubject odrl:target;
> odrl:constraintterm odrl:deleteAfter; {note: new term}
> odrl:operator odrl:eq ;
> odrl:rightoperandvalue "P30D"^^xsd:dateTime
> ]
> ] ;
> Human language variant of the triple:
> “the target of this policy” “has Delete After constraint” “equal – period of 30 Days (of type date)”
>
> odrl:constraint [
> a odrl:Constraint ;
> odrl:constraintsubject odrl:action;
> odrl:constraintterm odrl:purpose;
> odrl:operator odrl:eq ;
> odrl:rightoperandvalue p3p:contact
> ]
> ] .
> Human language variant of the triple:
> “the action of this permission” “has Purpose constraint” “equal – Contact (as defined by W3C’s P3P)”
>
> ======= END of examples
>
> ** Open syntax issues:
> - Policy-internal and -external constraint subjects:
> As outlined in my initial email the odrl:constraintsubject could be either a thing being the value of an entity of this policy (e.g. odrl:target, odrl:assigner, odrl:assignee, odrl:action) or a policy-external entity (e.g. specific event with id)
> Could the rule be:
> a) if the value of odrl:constraintsubject is from odrl namespace then the subject is the ancestor field/entity of this name in the hierarchy of this policy
> b) if the value of odrl:constraintsubject is from another namespace this is not field/entity of this policy.
> If this rule is too simple then we need an indicator of the type of the odrl:constraintsubject.
> - A facet of the above: how to express policy-internal subjects
> The subject of the constraint could be expressed by either the field/entity holding a value or by the value itself.
> From example 28 above: by odrl:target of by http://example.com/billie:888:personal-data <http://example.com/billie:888:personal-data>
> While the latter identifies directly the subject the first, the indirect variant also include the role of this person-data-thing in the policy. That’s why I have suggested using the field/entity.
> - Verbosity: for an easy understanding I have used quite verbose names, e.g. rightoperandvalue, could be shorted for a final specification.
>
> ** Open semantic issue: the semantics of the constraint terms (in the latest published draft at https://www.w3.org/TR/vocab-odrl/#constraintActions <https://www.w3.org/TR/vocab-odrl/#constraintActions>) must be checked if how the subject is constrained by this term is clear and unambiguous.
>
> I hope this helps getting the direction of my suggestion.
>
> Best
> Michael
>
> From: Ivan Herman [mailto:ivan@w3.org <mailto:ivan@w3.org>]
> Sent: Tuesday, November 8, 2016 7:09 AM
> To: Michael Steidl <mdirector@iptc.org <mailto:mdirector@iptc.org>>
> Cc: W3C POE WG <public-poe-wg@w3.org <mailto:public-poe-wg@w3.org>>
> Subject: Re: About a more strict definition of Constraint
>
> Michael,
>
> I *think* I see where you are going, but I am not sure. Could you give some explicit examples? For example, by re-writing some of the examples in
>
> https://www.w3.org/TR/vocab-odrl/ <https://www.w3.org/TR/vocab-odrl/>
>
> using your approach? It would help me at least to understand it better…
>
> Thanks
>
> Ivan
>
>
>> On 7 Nov 2016, at 18:57, Michael Steidl (IPTC) <mdirector@iptc.org <mailto:mdirector@iptc.org>> wrote:
>>
>> Hi all,
>> the recent discussion about Complex Constraints let me look into the current definition of Constraint [1].
>> I interpret this definition as:
>> - A constraint applies to the Permission, Prohibition or Duty as a whole. In RDF terminology one of these is the subject of the triple. And this definition is implicit – the subject is always the Permission (, Prohibition) or Duty including the constraint.
>> - The constraint data are “mathematical terms with two operands and one operator” = a mathematical, or better a Boolean, condition which has to be met.
>> - If multiple constraints with the same subject exist then all of them have to be met.
>>
>> From that I see two main open issues:
>>
>> A) To make the use of the subject of the constraint more flexible – and have an RDF triple in mind:
>> 1) I suggest to add an entity to Constraint expressing the subject explicitly. This entity could express that the whole Permission/Prohibition/Duty is the subject or a specific part of it – or an entity outside it, e.g. an event. In the latter case an identifier for this external entity should be added to the structure.
>> That a constraint is included into a Permission or Duty still defines which constraints have to be met to show a thumbs up for Permission or Duty.
>>
>> 2) I suggest to consider the current “name” of a constraint as the predicate of the triple.
>> E.g. Absolute Position -> “has absolute position constraint”, Resolution -> “has resolution constraint”
>>
>> 3) I suggest to consider the “mathematical terms” as the object of the triple.
>>
>> This could result in triples like (taken from discussions and use cases)
>> “The asset with id=’abc123’” “has resolution restriction” “operator=lowerThan rightOperand=300 unit=dpi”
>> “The assignee party” “has age restriction” “operator:higherThan rightOperand=18 unit=year”
>> “The assignee party” “has affiliation restriction” “operator:equal rightOperand= https://www.wikidata.org/entity/Q48282 <https://www.wikidata.org/entity/Q48282> “ (help: “student” entity of WikiData)
>> “The event with id=’http://sporteventregistry.com/abc9883’ <http://sporteventregistry.com/abc9883%E2%80%99>” “has temporal-after-terminated constraint” “operator=higherThan rightOperand=30 unit=minutes”
>> “This Duty” “has payment constraint” “operator=equal rightOperator=200 unit=EUR”
>>
>>
>> B) Clarification of processing multiple constraints
>> The current specs define that all constraints have to be met.
>> First clarification: is that sufficient – or not. If not: what are requirements going beyond that?
>> Note: I recall it was raised that some constraints may apply in temporal order – but why is this relevant? Again: all constraints have to be met, in this case the e.g. Permission is only given after the last constraint has been met. And if the permission may change after some time (or other fulfilled constraints) ODRL provides the nextPolicy.
>>
>> My approach is: it may help to have a more strict definition of constraint to solve some pending issues. Let’s consider that before digging into complexity.
>>
>> Best,
>> Michael
>>
>> [1] http://w3c.github.io/poe/model/#constraint <http://w3c.github.io/poe/model/#constraint>
>>
>>
>> Michael Steidl
>> Managing Director of the IPTC [mdirector@iptc.org <mailto:mdirector@iptc.org>]
>> International Press Telecommunications Council
>> Web: www.iptc.org <http://www.iptc.org/> - on Twitter @IPTC <http://www.twitter.com/IPTC>
>> Business office address:
>> 25 Southampton Buildings, London WC2A 1AL, United Kingdom
>> Registered in England, company no 101096
>
>
>
> ----
> Ivan Herman, W3C
> Digital Publishing Technical Lead
> Home: http://www.w3.org/People/Ivan/ <http://www.w3.org/People/Ivan/>
> mobile: +31-641044153
> ORCID ID: http://orcid.org/0000-0003-0782-2704 <http://orcid.org/0000-0003-0782-2704>
----
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
Received on Tuesday, 8 November 2016 14:47:47 UTC