3.7 Action

[simonstey]

Action contains the following attribute:
name: indicates the Action entity term (REQUIRED)

where is such a name attribute defined? e.g., the turtle serialization of ODRL doesn't contain any name attribute at all.

[nitmws]

I see it in the Information Model: http://w3c.github.io/poe/model/#action
The problem is that this name is transformed into the id of a specific action instance: e.g. the Display action (http://w3c.github.io/poe/vocab/#term-display) has an identifier http://www.w3.org/ns/odrl/2/display and the "display" of this URL is the name of the information model. Also not having a "name" in the tabular definition of Actions (http://w3c.github.io/poe/vocab/#actions) may cause confusion.

[riannella]

Section 4.13 of the Vocab spec is called "Names for Constraints".
The way that "name" was modelled in the ontology was as the subproperties of the rightOperand property. I suspect that was done to subsume the object.

In XML we would have:
<o:constraint name="http://www.w3.org/ns/odrl/2/dateTime"
operator="http://www.w3.org/ns/odrl/2/eq"
rightOperand="P30D"/>

Imagine the above where "rightOperand" is replaced with "odrl"dateTime"

[nitmws]

Sorry Renato, I can't follow this explanation. The Information Model shows for the Constraint class a name, operator and rightOperand and my understanding is what I wrote down in these proposals: https://www.w3.org/2016/poe/wiki/Constraints_in_the_Information_Model

In short: a constraint has a rule for comparing two values: one value defined by a left operand (defined as Name of Constraint in the vocabulary), a second value explicitly defined by the right operand (plus sub-properties like unit) and how they must be compared is defined by the operand. By that a "Name of a Constraint" is not the right but the left operand.

[riannella]

Yes, there is nothing wrong with the Info Model for Constraints. Which was verbatim modelled in XML for example, but the Ontology model took some liberties in how its expresses the same semantics. So, for example, there is no "name" property in the Ontology. It has been conflated into the rightOperand.

[nitmws]

Hmmmm, does this conflation express the information model correctly? I doubt.

The current Constraint defintion says - http://w3c.github.io/poe/model/#constraint

• Constraints express mathematical terms with two operands and one operator
• name: a name that identifies the left operand of the operation (REQUIRED)
• operator: an operator function (REQUIRED)
• rightOperand: the right operand of the operation (REQUIRED if no rightOperandReference)

The requirement regarding expressing this definition is that is must clearly state what is a constraint's left operand and right operand and what is the operator.

Example 3 in the Vocab/Encodings document - http://w3c.github.io/poe/vocab/#sc-example3 - shows:
odrl:constraint [
a odrl:Constraint ;
odrl:count 1 ;
odrl:operator odrl:lteq
]
I interpret these triples as I see/read them:

• thisConstraint isA ODRL-Constraint
• thisConstraint hasOperator "Lower Than or Equal"
• thisConstraint hasNumericCountOfExercisingTheAction*) "1"

*) Predicate based on the "clarified" definition of odrl:count, see https://www.w3.org/2016/poe/wiki/Constraints

The last triple asserts that the numeric count for exercising the action is equal to 1. I think this assertion is wrong as it could be less than 1! This kind of expression doesn't reflect what the left and the right operand is - these assertions get lost. It's only an ODRL internal interpretion that the predicate of a triple has to be matched against the object of the triple by the object of the triple with the hasOperator predicate.

I think such an RDF would reflect the definition by the Information Model unambigously:
odrl:constraint [
a odrl:Constraint ;
odrl:leftOperand odrl:count
odrl:rightOperand 1 ;
odrl:operator odrl:lteq
]
A bit more verbose but telling explicitly what should be told.

[riannella]

Perhaps we just need to explain this difference in the ontology model (vs the Info Model) in the Vocab/expression spec?

In essence, what the ontology model says is, take this:
odrl:leftOperand odrl:count
odrl:rightOperand 1 ;

and express it as this:
odrl:count 1 ;

[vroddon]

I believe the model gains at least in understandability, namely, a newcomer will intuitively understand the meaning. Víctor El 12/12/2016 a las 10:27, Michael Steidl escribió:

…

I think such an RDF would reflect the definition by the Information Model unambigously: odrl:constraint [ a odrl:Constraint ; odrl:leftOperand odrl:count odrl:rightOperand 1 ; odrl:operator odrl:lteq ] A bit more verbose but telling explicitly what should be told.

-- Víctor Rodríguez-Doncel D3205 - Ontology Engineering Group (OEG) Departamento de Inteligencia Artificial ETS de Ingenieros Informáticos Universidad Politécnica de Madrid Campus de Montegancedo s/n Boadilla del Monte-28660 Madrid, Spain Tel. (+34) 91336 3753 Skype: vroddon3

[nitmws]

Re @riannella: such a description could be written down but that means a receiver of such a policy has to read the spec document from A to Z to learn by one of its sections how to deal with that as in fact this design does not comply with RDF rules.
My approach for my alternative design was: stick to the RDF rules, make it easy to understand at first sight - @vroddon thanks for your comment supporting this assumption.

Another issue came up today: how to parse a constraint in RDF? For retrieving information about a resource it is common to check the defined properties of a class. Example: a FOAF Person has a firstName and a surname and some "knows" relationships to other persons, the assumption that these properties exist as predicates of RDF triples is based on the definition of this class - http://xmlns.com/foaf/spec/#term_Person

For an ODRL constraint a left and a right operand and an operator are REQUIRED properties = they MUST be there. A parser will easily find the operator, but how to find the operands? A leftOperand doesn't have to be defined by ODRL, any "Name of Constraint" defined by any party could be used there. So how should the poor parser find out that a predicate like iptc:usagePeriod is the left operand - what makes this predicate special to know/assume/guess/hope that this is the left operand? Defining that a constraint must consist of only three assertions - one about the type, one for the operator, one for the left and right operand - doesn't work in practice as the Constraint class also defines optional properties.

[riannella]

@nitmws What rdf rules are not being complied with?

For the required properties, we have issue ##26
that asks for more detailed axioms in the ontology. So, in your case, do we define Constraint as a defined class with the mandatory properties? (and someone to volunteer to do it ;-)

[nitmws]

@riannella I'm not a deep RDF expert like @iherman but an RDF user with a focus on metadata of media assets. So let me modify my statement: a thisConstraint-leftOperand-rightOperand triple does not assert what it should by expressing a class definition by RDF.

The RDF 1.1 Concepts and Abstract Syntax - https://www.w3.org/TR/rdf11-concepts - defines: "Asserting an RDF triple says that some relationship, indicated by the predicate, holds between the resources denoted by the subject and object." And about a class in an ontology context it is usually said that it defines a set of commonon characteristics of objects of this class. That results in such assertions: an instance of a class is the subject of the RDF triple, a "common characteristic" - called property - is the predicate and the value of the characteristic is the object.

And e.g. Dublin Core defines the DC Term license this way (not all properties included):

dcterms:license
    a rdf:Property ;
    dcterms:hasVersion <http://dublincore.org/usage/terms/history/#license-002> ;
    dcterms:issued "2004-06-14"^^<http://www.w3.org/2001/XMLSchema#date> ;
    rdfs:comment "A legal document giving official permission to do something with the resource."@en.

Let's have a look at the RDF triple
thisConstraint odrl:count "1"
This triple consists in fact of: the subject thisConstraint is ok, but the predicate is the object of a triple with odrl:leftOperand as predicate and the object is the object of a triple with odrl:rightOperand as predicate. The style "express the objects of two defined properties of a class as predicate and object of a (special) triple" does not follow this "express a class by RDF (triples)" design.

[riannella]

@nitmws are you concerned that when you read:
odrl:count 1
that this is interpreted as "the odrl:count is 1" ?

[nitmws]

@riannella yes, to be precise it could be read as: "this constraint's odrl:count is 1" ... and odrl:count is not a property of the class Constraint.

[riannella]

This is a significant change, as it will fundamentally change the current rightOperand property.
Hence, the decision is beyond this Github Issue discussion, and must be taken the to WG for a decision.
Can @nitmws and @vroddon work on a detailed proposal (including the proposed ontology change) and submit that to the WG for discussion/resolution?

[nitmws]

@riannella I followed your advice and started issue #84 about that topic. @vroddon could you have a look at that, please?

[riannella]

Closing this issue - as it now appears as #81