search

w3c / poe

Permissions & Obligations Expression WG
Other
23 stars 18 forks source link

Review definition of Constraint by ODRL ontology #84

Closed nitmws closed 7 years ago

nitmws commented 7 years ago

The discussion under issue #79 raised in a sub-thread the question: are the key items of the mathematical/logical expression/comparison of a constraint - left operand, right operand and operator - as defined by the Information Model (http://w3c.github.io/poe/model/#constraint) well defined in the current draft ODRL Ontology (http://w3c.github.io/poe/vocab/ODRL22.ttl)

This issues should review that and propose changes if required.

nitmws commented 7 years ago

Current status of the definitions of Constraint

... with a focus on left operand, right operand and operator

By the Information Model

See http://w3c.github.io/poe/model/#constraint

By the ODRL Ontology

See its Turle serialization: http://w3c.github.io/poe/vocab/ODRL22.ttl

The Constraint Class

:Constraint
    a rdfs:Class, owl:Class ;
    rdfs:isDefinedBy odrl: ;
    rdfs:subClassOf owl:Thing ;
    rdfs:label "Constraint"@en ;
    skos:definition "The Constraint entity indicates limits and restrictions to the Permission, the Prohibition and the Duty entity"@en ;
    skos:note "Parent class of all Constraints."@en .

The definition of this class does not include properties. Therefore properties with the rdfs:domain :Constraint were filtered:

:unit
    a rdf:Property ;
    rdfs:isDefinedBy odrl: ;
    rdfs:domain :Constraint ;
    rdfs:range rdfs:Resource ;
    rdfs:label "Unit"@en ;
    skos:definition "The unit of measurement used for the constraint value."@en .

:dataType
    a rdf:Property ;
    rdfs:isDefinedBy odrl: ;
    rdfs:domain :Constraint ;
    rdfs:range rdfs:Resource ;
    rdfs:label "Datatype"@en ;
    skos:definition "The datatype used for the constraint value."@en ;
    skos:note "In RDF encodings, use of the rdf:datatype MAY be used".

:operator
    a rdf:Property , owl:ObjectProperty ;
    rdfs:isDefinedBy odrl: ;
    rdfs:label "Has Operator"@en ;
    skos:definition "The Boolean operator applied to a constraint and its operand."@en ;
    rdfs:domain :Constraint ;
    rdfs:range :Operator .

:rightOperand
    a rdf:Property ;
    rdfs:isDefinedBy odrl: ;
    rdfs:label "Right Operand"@en ;
    skos:definition "The operand applied to an instance of a constraint."@en ;
    skos:note "Do not use the right-operand property directly within a Constraint. Instead, a Constraint instance must contain exactly one triple which makes use of one of the sub-properties of right-operand."@en ;
    rdfs:domain :Constraint .

:status
    a rdf:Property ;
    rdfs:isDefinedBy odrl: ;
    rdfs:label "Status"@en ;
    skos:definition "The current value of the constraint."@en ;
    skos:note "The range of the status property is identical to that of the operand property selected used in the constraint."@en ;
    rdfs:domain :Constraint ;
    skos:scopeNote "Non-Normative"@en .

Left operands are not explicitly defined. Searching for known instances of "Name of Constraint" such a definition can be found:

:count
    a rdf:Property , owl:DatatypeProperty ;
    rdfs:isDefinedBy odrl: ;
    rdfs:subPropertyOf :rightOperand ;
    rdfs:label "Count"@en ;
    skos:definition "The numeric count indicating the number of times the corresponding entity may be exercised"@en ;
    skos:note "Should be a positive integer"@en ;
    rdfs:range xsd:nonNegativeInteger .

This example shows that left operands are defined as subProperty of :rightOperand. So what is an rdfs:subPropertyOf:

nitmws commented 7 years ago

Comment on the implementation of the Constraint class by the ODRL Ontology

The basic requirement from the Information Model (IM) is: the required properties name (=left operand), operator and right operand(-reference) must be available in the Ontology.

The operator and the righOperand are defined as properties of the Constraint class, that is ok - but not completely, the definition of the semantics have changed:

I think making left operands a sub-property of the right operand is an error. Example draft:

:thisConstraint
  odrl:operator odrl:lt
  odrl:rightOperand "10"
OR
  odrl:count "10"

In this example the triple thisConstraint odrl:rightOperand "10" could/should be replaced by thisConstraint odrl:count "10" Syntactically - property replaced by sub-property - this may be ok, but this raises the issue: using a subPropertyOf means a predicate with narrower but the same basic semantics is used. BUT: odrl:count is not a narrower right operand, it is meant to be a left operand. AND: where is syntactically the left operand required by the Constraint class? Example for the relationship property/sub-property: the Cambridge Semantics example above asserts ex:Mother rdfs:subPropertyOf ex:Parent Let's look at alternatives: ex:Father rdfs:subPropertyOf ex:Parent sounds ok ex:Employee rdfs:subPropertyOf ex:Parent sounds awkward as Employee doesn't have basically the same, but narrower semantics than Parent.

Therefore my basic proposal is:

vroddon commented 7 years ago

If I understand well, the resulting expression would be:

:thisConstraint
  odrl:operator odrl:lt
  odrl:rightOperand "10"
  odrl:leftOperand odrl:count ;

I am very happy with this change. Everything is far cleaner now.

vroddon commented 7 years ago

I have changed the ttl file and the index.hml. I have uploaded the changes in the git into a new branch named issue84. I DONT KNOW HOW TO PROCEED: a) Push directly the changes to branch gh-pages b) Wait for your approval

(for the moment I wait)

vroddon commented 7 years ago

Actions taken in the uploaded version as branch issue84:

nitmws commented 7 years ago

@vroddon a few comments on the ODRL22.ttl in the issue84 branch - changes shown as bold:

I see no need for other changes of the Ontology.

vroddon commented 7 years ago

I have effected the changes, again pushing only in the github branch issue84

Regards, Víctor

El 19/12/2016 a las 9:41, Michael Steidl escribió:

@vroddon https://github.com/vroddon a few comments on the ODRL22.ttl in the issue84 branch - changes shown as bold:

  • The issue date should be set to a recent date - to make clear "this is a newer version as the one of 5 July 2016"
  • :rightOperand refers to RightOperandReference - but this thing does not exist in this file, only a first suggestion?
  • :LeftOperand skos:definition: "Left operands for constraint expressions."@en https://github.com/en ; (operator -> operand)
  • :operator skos:definition: "The Boolean operator applied to a constraint and its operands."@en https://github.com/en ; (operands in plural, we have two!)
  • :status skos:note : needs rewording as there is not a single operand property anymore

I start with: skos:note "The range of the status property is identical to that of the constraint expression."@en ;

I see no need for other changes of the Ontology.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c/poe/issues/84#issuecomment-267910220, or mute the thread https://github.com/notifications/unsubscribe-auth/AFLs5a7zTdd7V9wAYxxauHI174micFpnks5rJkNNgaJpZM4LPC1T.

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

riannella commented 7 years ago

Should we then also change Constraint "name" in the Info Model to "leftOperand" to make it abundantly clear?

The name of the SKOS Collection in the Ontology can also become "Constraint Left Operands"?

Set the label for leftOperand to be "Has Left Operand".

policyUsage should be an Individual of class Right Operand now.

riannella commented 7 years ago

We should also add skos:historyNote to the updated terms to indicate the changes.

iherman commented 7 years ago

I try to understand how this would work, because I am still a bit messed up.

I take on example from the ODRL2.1 which says:

_:requirements
    a odrl:Duty ;
    odrl:constraint [
        a odrl:Constraint ;
        odrl:payAmount 50.00 ;
        odrl:operator odrl:eq ;
        odrl:unit <http://cvx.iptc.org/iso4217a:AUD>
    ] .

In the new ontology, payAmount is defined as a Left Operand. Is it so that, under the new proposal, the example above would look like:

_:requirements
    a odrl:Duty ;
    odrl:constraint [
        a odrl:Constraint ;
        odrl:leftOperand odrl:payAmount ;
        odrl:operator odrl:eq ;
        odrl:rightOperand 50.00 ;
        odrl:unit <http://cvx.iptc.org/iso4217a:AUD>
    ] .

If so, this indeed looks way cleaner. It does smell like reification but this does not say that the resulting RDF graph includes any newer triple of the form (XYZ odrl:eq 50.00) or anything similar, i.e., this is not reification. In other words, although we do say that a particular relationship holds, we do not claim this relationship is part of any RDF graph. And that is fine.

Again if my understanding is correct, I am fine with it. However, I am not sure what the role/usage of odrl:RightOperandReference is. The current ontology creates a union of this stuff with xsd:any, and is used as a possible range of rightOperand. But because one of the elements of the union is xsd:any, what does odrl:RightOperandReference brings to the table? After all, anything can be a right operand (and, at this point, I believe this is the right thing to do)...

vroddon commented 7 years ago

Hi Ivan,

I think you have understood it correctly, we only have to write the spec so that it is clear beyond doubt for you and for any reader. Regarding the meaning of |odrl:RightOperandReference|, I believe it clarifies the semantics of the attribute: value or reference?

In the given example the rightOperand was a number, which is quite different from URI. But consider the case when the rightOperand is naturally a URI itslef. How to know if the right operand is the given URI or the reference? I do believe there is no other way but defining the |odrl:RightOperandReference.|

Regards, Víctor

El 05/01/2017 15:23, Ivan Herman escribió:

I try to understand how this would work, because I am still a bit messed up.

I take on example from the ODRL2.1 https://www.w3.org/ns/odrl/2/ODRL21#sec-examples which says:

_:requirements a odrl:Duty ; odrl:constraint [ a odrl:Constraint ; odrl:payAmount 50.00 ; odrl:operator odrl:eq ; odrl:unit http://cvx.iptc.org/iso4217a:AUD ] .

In the new ontology, |payAmount| is defined as a Left Operand. Is it so that, under the new proposal, the example above would look like:

_:requirements a odrl:Duty ; odrl:constraint [ a odrl:Constraint ; odrl:leftOperand odrl:payAmount ; odrl:operator odrl:eq ; odrl:rightOperand 50.00 ; odrl:unit http://cvx.iptc.org/iso4217a:AUD ] .

If so, this indeed looks way cleaner. It does smell like reification but this does /not/ say that the resulting RDF graph includes any newer triple of the form |(XYZ odrl:eq 50.00)| or anything similar, i.e., this is /not/ reification. In other words, although we do say that a particular relationship holds, we do not claim this relationship is part of any RDF graph. And that is fine.

Again if my understanding is correct, I am fine with it. However, I am not sure what the role/usage of |odrl:RightOperandReference| is. The current ontology creates a union of this stuff with |xsd:any|, and is used as a possible range of |rightOperand|. But because one of the elements of the union is |xsd:any|, what does |odrl:RightOperandReference| brings to the table? After all, /anything/ can be a right operand (and, at this point, I believe this is the right thing to do)...

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/w3c/poe/issues/84#issuecomment-270654939, or mute the thread https://github.com/notifications/unsubscribe-auth/AFLs5bl18_xxWnZAsfa1nUkE0Ej-Vmjmks5rPPzXgaJpZM4LPC1T.

-- Víctor Rodríguez-Doncel D3205 - Ontology Engineering Group (OEG) Departamento de Inteligencia Artificial Facultad de Informática Universidad Politécnica de Madrid

Campus de Montegancedo s/n Boadilla del Monte-28660 Madrid, Spain Tel. (+34) 91336 3672 Skype: vroddon3

El software de antivirus Avast ha analizado este correo electrónico en busca de virus. https://www.avast.com/antivirus

nitmws commented 7 years ago

Hi @iherman the updated Information Model ED shows already an examples of such a constraint of a duty - http://w3c.github.io/poe/model/#duty 

        "duty": [{
            "action": "odrl:compensate",
            "constraint": [{
                "name": "odrl:payAmount",
                "operator": "odrl:eq",
                "rightOperand": "5.00",
                "unit": "http://cvx.iptc.org/iso4217a/AUD"
            }],

In #81 Renato said it should be discussed if the property "name" should become a "leftOperand" in the ontology - as "name" is used since ODRL 2.0 and this would be a remarkable renaming. But that's more a backward compatibility/documentation terminology issue than an ontology issue.

iherman commented 7 years ago

On 5 Jan 2017, at 15:33, Víctor Rodríguez-Doncel <notifications@github.com mailto:notifications@github.com> wrote:

Hi Ivan,

I think you have understood it correctly, we only have to write the spec so that it is clear beyond doubt for you and for any reader. Regarding the meaning of |odrl:RightOperandReference|, I believe it clarifies the semantics of the attribute: value or reference?

In the given example the rightOperand was a number, which is quite different from URI. But consider the case when the rightOperand is naturally a URI itslef. How to know if the right operand is the given URI or the reference? I do believe there is no other way but defining the |odrl:RightOperandReference.|

If this is all you want to do, why don't you use [anyURI from xsd](https://www.w3.org/TR/xmlschema-2/#anyURI https://www.w3.org/TR/xmlschema-2/#anyURI)? Why introducing a new type for this?

riannella commented 7 years ago

@iherman there is a semantic difference. The requirement is to support the declaration of the rightOperand as the actual value, eg "10", "Canada", "2017-01-01" or "http://w3.org/" AND as a de-reference-able URI. The latter then would HAVE to be de-refed to get the actual value of the rightOperand.

Hence, RightOperandReference may be "http://weather.com/brisbane/today" and you have to deref it to get "30"

iherman commented 7 years ago

Ah. O.k., I get it.

On 8 Jan 2017, at 01:45, Renato Iannella <notifications@github.com mailto:notifications@github.com> wrote:

@iherman https://github.com/iherman there is a semantic difference. The requirement is to support the declaration of the rightOperand as the actual value, eg "10", "Canada", "2017-01-01" or "http://w3.org/ http://w3.org/" AND as a de-reference-able URI. The latter then would HAVE to be de-refed to get the actual value of the rightOperand.

Hence, RightOperandReference may be "http://weather.com/brisbane/today http://weather.com/brisbane/today" and you have to deref it to get "30"

riannella commented 7 years ago

WG agreed to this change (9 JAN 2017)

riannella commented 7 years ago

@nitmws @vroddon Can you please make these changes (now approved by the WG) and merge the github branch back into the main branch.

riannella commented 7 years ago

I suggest we also rename "name" to leftOperand in the Info Model. (For the XML encoding, we will still use "name" with a note to indicate the mapping)

vroddon commented 7 years ago

Sure! I will make the changes tomorrow.

El 10/01/2017 a las 2:02, Renato Iannella escribió:

@nitmws https://github.com/nitmws @vroddon https://github.com/vroddon Can you please make these changes (now approved by the WG) and merge the github branch back into the main branch.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c/poe/issues/84#issuecomment-271456457, or mute the thread https://github.com/notifications/unsubscribe-auth/AFLs5blGjQzWP4r3vqKdLTFPBm4xO7riks5rQtiTgaJpZM4LPC1T.

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

vroddon commented 7 years ago

Done. As soon as it gets approved I will delete the branch84 in the repo.