Action's refinement (also operands and operators)

[AndreaCimminoArriaga]

In many scenarios, the Actions (and operands and operators) need extra information to work properly. In the formal semantics document there is a good example of this need.

{
     "@context": "http://www.w3.org/ns/odrl.jsonld",
     "@type": "Set",
     "uid": "http://example.com/policy/14",
     "permission": [{
        "target": "http://example.com/document/1234",
        "assigner": "http://example.com/party/616",
        "action": [{
           "rdf:value": { "@id": "odrl:print" },
           "refinement": [{
              "@id": "http://example.com/refinement/14"
              "leftOperand": "resolution",
              "operator": "lteq",
              "rightOperand": { "@value": "1200", "@type": "xsd:integer" },
              "unit": "http://dbpedia.org/resource/Dots_per_inch"
            }]
        }]
      }]
}

This policy describes that the action print, which needs to know an output resolution of 1200

• From the semantic point of view, the way of defining the parameter needed for the action is a bit odd since it is the same as how constraints are defined, but in this case this is not a constraint (the action resolution may have different options and we are only specifying one). It would make more sense to have something like:

_:b0 odrl:refinement [
                 a odrl:Resolution ;
                 odrl:resolutionValue "1200"^^xsd:integer
] .

• Also, from the point of view of semantics, how could we handle the case more than one refinement is needed? for instance, we need also to specify the output port HDMI1. Following the previous example:

                a odrl:Resolution ;
                odrl:resolutionValue "1200"^^xsd:integer
] , [
                a odrl:OutputPort ;
                odrl:portValue ni:HDMI1 ; # Having the port as a named individual
]

However, from the implementation point of view, the refinements defined hold no order (something that could be paramount for the enforcement from the coding point of view).

Something similar happens with operands and operators. What if an operator needs to be feeded with 3 arguments instead than just left and right? For the operands, for instance, dateTime, how can someone specify the time zone ?

These are considerations that could be interesting to bear for the future. IMHO a good approach to encode these elements could be following a similar approach as geosparql for their functions.

[joshcornejo]

More than one refinement is done by logical constraints and their operators (and, or, xone, andSequence).

md:uri:225b96258645:23249 a odrl:Action;
                          rdf:value odrl:concurrentUse,
                                    odrl:play;
                          odrl:refinement md:uri:225b96258645:23250.
md:uri:225b96258645:23250 a odrl:LogicalConstraint;
                          odrl:and md:uri:225b96258645:23251,
                                   md:uri:225b96258645:23252,
                                   md:uri:225b96258645:12699.

251 /252 / 699 are constraints:

md:uri:225b96258645:23251 a odrl:Constraint;
                          odrl:leftOperand odrl:recipient;
                          odrl:operator odrl:isPartOf;
                          odrl:rightOperand md:uri:225b96258645:23253R.
md:uri:225b96258645:23252 a odrl:Constraint;
                          odrl:leftOperand odrl:count;
                          odrl:operator odrl:lteq;
                          odrl:rightOperand md:uri:225b96258645:23254R.

[AndreaCimminoArriaga]

Yes, but I think the refinements stand for a certain additional information that, in this case, an action demands. It's a bit odd, at least to me, that such information is a constraint (also, only a binary constraint).

I think bearing in mind these considerations for the future may help. In any case, personally, I would follow a similar approach as geosparql. Although this may entail aligning more than a bit with SPARQL.

[joshcornejo]

I don't quite follow the "certain additional information that, in this case, an action demands". I can gather from some of your comments that you are also foreseeing "cascading chains" for other actions/parties downstream, but I would first figure if we can model them as chains of rules - maybe what's missing is a "different" specialisation of odrl:failure (i.e. when an actor tries an action prohibition is activated => execute a rule to inform the GDPR officer).

There is a requirement for a digital twin <-> ODRL ecosystem, and they want to use GeoSPARQL to represent the different locations where the real asset has been sourced from.

Quite a cool idea ... but when I read the spec (coordinates/grids/spatial references) - it would take forever to build the UI to start.

[AndreaCimminoArriaga]

During the evaluation the evaluator (software) must know the resolution that is written in the policy since it is need by the action implementation; without such value is unlike that the action print can be performed. Therefore, the resolution is additional information related to the print action, and in particular, in this use case. Note that the term odrl:print does not describe any mandatory need to know the resolution (see below the definition of this term in the ontology).

:print a :Action, skos:Concept ;
	rdfs:isDefinedBy odrl: ;
	rdfs:label "Print"@en ;
	skos:definition "To create a tangible and permanent rendition of an Asset."@en ;
	skos:note "For example, creating a permanent, fixed (static), and directly perceivable representation of the Asset, such as printing onto paper."@en ;
	:includedIn odrl:use ;
    skos:scopeNote "Non-Normative"@en .

Therefore, in order to perform this action during the evaluation, in this particular use case, the resolution is needed. My comment is that it's a bit odd that such information is codified as an odrl constraint since it is not a constraint per se but rather a parameter required by the action to be performed. I think it would be a good thing to have a bespoke approach to represent this kind of information.

I do not follow you comment on the cascading chains, can you expand it?

Regarding geosparql, I do not refer to they way aswkt points are expressed, but rather the functions defined to work with sf:Points and sg:Geometries. But again, this is a big step since it will impose heavy implementation restrictions. However, it may also bring benefits, as defining
only once the functions for ODRL and everybody will use the same implementation avoiding multiple implementations with diverse understanding on the standard terms.