Re: The crazy 'qualified' idea:-)

The problem, in PROV-O at least, is that the qualified version of the relationship is defined _instead of_ rather than on top of the regular relationship (compare prov:wasAssociatedWith with prov:qualifiedAssociation at https://www.w3.org/TR/prov-o/#qualifiedAssociation).
This makes the OWL cleaner, but a pain for consumers who have to play hunt the predicate.
If you want to keep the regular relationship, you have to state things twice (or rely on inferencing, which I wouldn’t assume in a consumer).

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 difference is that you use the same predicate as for the regular relationship, and the intermediate Role is inserted as a proxy, so that a consumer only needs to chain through the same predicate on either side to get to the ‘unqualified’ target.
It is more of a convention than a rule, and schema.org’s use of it is a little sketchy, but as a consumer it makes much more sense (say, if you load this stuff into a graph store).

Ivan’s sample then becomes:

odrl:ConstraintRole rdfs:subClassOf schema:Role . # not necessary, but playing nice

:aRule odrl:constraint [
            a odrl:ConstraintRole ;
            odrl:constraint :aConstraint .
            # any other properties one wants to attach here.
] .

Ontologically, this can be made consistent by adding ConstraintRole to both the domain and range of odrl:constraint.

Having dealt with trying to implement the PROV-O approach, and the twists you get yourself into trying to justify the relationships you inevitably need to dream up on the right hand side of these qualified constructs, reusing the same predicate makes much more sense. At Wiley, at least, we have adopted schema:Role as the common approach for N-ary relationships, in other words saying useful things about relationships themselves rather than the things attached to either end of them.
We have successfully incorporated this into our more formal ontological framework.

chz
Patrick Johnston
John Wiley & Sons


From: Ivan Herman <ivan@w3.org>
Date: Monday, October 10, 2016 at 9:32 AM
To: W3C POE WG <public-poe-wg@w3.org>
Subject: The crazy 'qualified' idea:-)
Resent-From: W3C POE WG <public-poe-wg@w3.org>
Resent-Date: Mon, 10 Oct 2016 13:32:44 +0000

Guys,

I promised on the call that I would jot down the the line of thought I had based on the Prov ontology 'qualified' approach[1]. Here it is...

If my understanding is correct, the way a constraint is used in the current (RDF version of) the ODRL model is something like:

:aRule odrl:constraint :aConstraint .
:aRule a odrl:Rule .
:aConstraint a odrl:Constraint .

If we use the approach used by the Prov vocabulary[1], we would have an _additional_ property, called odrl:qualifiedConstraint. It usage would be something like:

:aRule odrl:qualifiedConstraint [
            a odrl:QualifiedConstraint ;
            odrl:theConstraint :aConstraint .
            # any other properties one wants to attach here.
] .

It is like putting a more complex object instead of a simple predicate. Of course, I can also give it a URL:

:myOwnQualifiedConstraint
            a odrl:QualifiedConstraint ;
            odrl:theConstraint :aConstraint .

and use

:aRule odrl:qualifiedConstraint :myOwnQualifiedConstraint .

(ie, the "real" constraint is hidden)

If I use 'anotherConstraint' to express some time limit, then I may be able to do something like:

:aRule odrl:qualifiedConstraint :myOwnQualifiedConstraint .
:myOwnQualifiedConstraint odrl:constraint :anotherConstraint .

Or, let us say I have three constraints, and I want to express that I need the OR of those:

:myOwnQualifiedConstraint1 a odrl:qualifiedConstraint .
:myOwnQualifiedConstraint2 a odrl:qualifiedConstraint .
:myOwnQualifiedConstraint3 a odrl:qualifiedConstraint .
:aRule odrl:constraint [
            a odrl:OrCombination, odrl:Constraint ;
            odrl:onConstraints (:myOwnQualifiedConstraint1 :myOwnQualifiedConstraint2 :myOwnQualifiedConstraint3)
] .

I am not sure it all works but may worth some thoughts.

Note that this structure is _on top_ of the existing one. In other words, if a user does not want to use these complex solutions, then he/she can safely forget about them.

Ivan

[1] http://www.w3.org/TR/2013/REC-prov-o-20130430/


----
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