Re: The crazy 'qualified' idea:-)

Thx, I mostly just didn’t want to see you guys disappear down the PROV-O approach without understanding how less than ideal it is in terms of user experience. You do have the same issue with odrl:Party, in that it’s not designed transitively, which is what I was trying to get to with the use of schema:Role. So, for example, I shouldn’t write:

:aPolicy odrl:assignee [
a odrl:Party ;
odrl:assignee :aPerson
] .

because I assume* that an odrl:Party is really implementing the party data model pattern from relational database design (http://tdan.com/a-universal-person-and-organization-data-model/5014), and that actually _means_ something: a {:Person OR :Organization OR :System… [choose your ontology here]}, and you having an assignee of any one of these doesn’t fit. schema:Role is literally a proxy for the relationship, nothing more: its properties always belong to the relationship it is proxying and it has no context outside of that instance. It’s the manifestation of a truly blank node….

*perhaps incorrectly, but all the examples at https://www.w3.org/ns/odrl/2 have fully realized URLs which implies they have a context outside the relationship.

Having said all that, for constraints on constraints, I prefer the simpler recursive model you put in a further email Renato. It is relatively intuitive to think of a constraint on a constraint as a further restriction. This can also be relatively easily queried in, say, SPARQL. I am assuming here that any peer constraints are treated as AND, so that this is all consistent.

p

From: Renato Iannella <renato.iannella@monegraph.com>
Date: Friday, October 14, 2016 at 2:15 AM
To: W3C POE WG <public-poe-wg@w3.org>
Subject: Re: The crazy 'qualified' idea:-)
Resent-From: W3C POE WG <public-poe-wg@w3.org>
Resent-Date: Friday, October 14, 2016 at 2:16 AM


On 14 Oct. 2016, at 03:12, Johnston, Patrick - Hoboken <pjohnston@wiley.com<mailto:pjohnston@wiley.com>> wrote:

There is another model that is a little more intuitive to implementers and consumers evinced by schema:Role (see http://blog.schema.org/2014/06/introducing-role.html).

The ODRL Information Model [1] has similarly used a Role and Relation class (between Party and Asset respectively).

But this has been modelled (or “flattened") to properties in the ODRL Ontology (to save reification I assume).

We then define an abstract property (eg function) and subproperties [2] to use as properties in your ODRL expression.

This would not work for our “constraints on constraints” need as is, as there are no explicit dependencies across the subproperties.


Renato Iannella, Monegraph
Co-Chair, W3C Permissions & Obligations Expression (POE) Working Group

[1] https://w3c.github.io/poe/model/fig/00Model.png

[2] https://w3c.github.io/poe/vocab/#partyRoles