Examples of formal semantics

[vroddon]

With Nicoletta's help, I have just updated one of the examples for state of the art (state C12). Example and link follows. Observations:

• It is now valid RDF. We should check the syntax of all the files...
• We represented currentTime directly with a literal. Beatriz was proposing an intermediate resource. Was there any particular reason?
• We are unsure about using odrl:payAmount, odrl:payee, and odrl:compensate. By using odrl:payAmount and odrl:payee as properties and odrl:compensate as owl:Class we are extending the official semantics (not illegal, but not a very nice practice). By declaring new elements we are overload the user (not a very nice practice). I would like to discuss which is your best approach.
• Actions may not be instant. I suggest using prov-o for not instantaneous actions (e.g. watch a movie between 10:00 and 12:00). By using prov-o we are also supporting actions that result in the creation of other assets.

@prefix odrl: <http://www.w3.org/ns/odrl/2/> .
@prefix party: <https://ex.org/party#> .
@prefix ex:   <https://ex.org/> .
@prefix sotw: <https://ex.org/sotw#> .
@prefix dcterms: <http://purl.org/dc/terms/> .
@prefix xsd:     <http://www.w3.org/2001/XMLSchema#> .

  ex:sotw a sotw:SotW;                                   #ex:sotw is a particular state of the world
    sotw:id <http://example.com/policy/state/C12>;
    sotw:currentTime "2025-07-27T00:00:00Z"^^xsd:dateTime; #TO BE DISCUSSED: Beatriz was proposing using an intermediate URI. Why?
    sotw:action [                                       #sotw:action is an action that actually took place (what the evaluator knows)
      a ex:Compensate;                                  #Observation: we may use odrl:compensate if also declared to be an owl:Class.
      ex:payAmount "5.00"^^xsd:decimal;                 #We avoid using odrl:payAmount, for it is not meant to be used as a property.
      odrl:payee party:sony;
      dcterms:issued "2025-07-23T00:00:00Z"^^xsd:dateTime  #Idea: if the action is a prov:Activity, then we can have start and end time for the action.  
    ] .

Is this version ok for you?

[joshcornejo]

IMHO currentTime should be external to any declaration of policy or state, unless there is an assumption that at any point, any query will automatically receive the correct time assigned to the SoTW.

[AndreaCimminoArriaga]

I have a few questions and comments:

• Why do we need to have a sotw:id, why not having <http://example.com/policy/state/C12> as the subject of these triples ? that is the ID of this state of the world right? when translated into JSON-LD 1.1 that URI should go under @id.
• It is now valid RDF. We should check the syntax of all the files I can do this if you want
• Actions may not be instant. I suggest using prov-o for not instantaneous actions (e.g. watch a movie between 10:00 and 12:00). By using prov-o we are also supporting actions that result in the creation of other assets. I like this idea very much.
• About extending or not the ontology, I think this is something it will be inevitable for ODRL since as it is now it lacks of specific semantics that are needed (I bore you all with this all the time, sorry :) )
• I also agree with @joshcornejo that some values of the RDF are not stone written in the RDF (like the current date time). If the current date time is written it becomes a past date time, therefore it is needed to define a special kind of data that is fetched dynamically, maybe specifying that the evaluation should rely on an API or querying a database.
• I may be wrong but, after checking it, the ODRL ontology defines the term odrl:Action but the class has no data properties defined as those in the example provided.
• I think it would be better to have the sotw:currentTime in a separate term. A problem I foresee with this example is that in this case it is only needed the currentTime but what about needing more contextual information; for instance the ID of the user, the currentTime, and the state of a sensor (e.g. open/closed). In this case the value of each of these properties will be a data property of the class sotw:SoTW. IMHO this will be hard to scale as use cases will kick-in, instead by defining an intermediate term that could be adapted to the different use cases by extending it will help and also will enable the class sotw:SoTW to have multiple values. An example of how it could look like is the following, don't take into account the names of the classes as I did this quick:

With the previous ontology the example would look like

@prefix odrl: <http://www.w3.org/ns/odrl/2/> .
@prefix party: <https://ex.org/party#> .
@prefix ex:   <https://ex.org/> .
@prefix st: <http://example.com/policy/state/>
@prefix sotw: <https://ex.org/sotw#> .
@prefix dcterms: <http://purl.org/dc/terms/> .
@prefix xsd:     <http://www.w3.org/2001/XMLSchema#> .

  st:C12 a sotw:SotW;                             
   sotw:hasContextualData [
           a sotw:StaticContextualData;
           sotw:describesFeature sotw:IoTData ;
           sotw:value "Closed"
    ], [
           a sotw:StaticContextualData;
           sotw:describesFeature sotw:AuthorizationCredentials ;
           sotw:value "XXXX" # whatever value here
    ], [
           a sotw:DynamicContextualData;
           sotw:describesFeature sotw:TemporalData ;
           sotw:expected xsd:dateTime 
           # This instance could be even linked to a policy if needed, kind of declaring a variable
    ];



    sotw:action [                                      
      a ex:Compensate;                                  
      ex:payAmount "5.00"^^xsd:decimal;                 
      odrl:payee party:sony;
      dcterms:issued "2025-07-23T00:00:00Z"^^xsd:dateTime 
    ] .

[joshcornejo]

Why do we need to have a sotw:id, why not having http://example.com/policy/state/C12 as the subject of these triples ? that is the ID of this state of the world right? when translated into JSON-LD 1.1 that URI should go under @id.

I have used decentralised ID to represent the sotw, and you can have more than 1 agreement ("Andrea can access all these assets that have these policies when he is in UPM") - there is a minimum 1:1 mapping between the Agent/Party and a StoW (in practice, there is nothing preventing a 1:N as in OIDC you can have many claims).

I also agree with @joshcornejo that some values of the RDF are not stone written in the RDF (like the current date time). If the current date time is written it becomes a past date time, therefore it is needed to define a special kind of data that is fetched dynamically, maybe specifying that the evaluation should rely on an API or querying a database.

This comes to what is internal to the Stow (like the assignee) vs what is external (current time), there will be plenty of attributes (as I mentioned on Monday - more around the 'current' state of an Agent) that will only be known when the client makes a request, at the point that request is made (e.g. you can only watch this movie in Spain, can only be evaluated when we know who is "you" and "where is you").

Other problems will surface as well - like control/setting over certain attributes isn't client-driven but evaluator-driven (date time is a good example, i will leave it as an exercise to discover others).

Finally, if you want to secure the stow - there are other aspects missing (e.g. you can see policies because they are public, but not state because nobody should know if i am in Spain or not).

[vroddon]

1) On the subject
I am not sure of having understood @joshcornejo. Do we all agree that http://example.com/policy/state/C12 should be the subject of these triples?
2) On the currentTime
I like the ideas of DynamicContextualData etc. Does anybody dissent?

Can we produce a new version of "state C12"?

[joshcornejo]

1. st:C12 is a good example of a id

2. I don't disagree but not sure what is it's practical "use" is considering these are documents and can be modified before entering the evaluator, and as an evaluator, I know what I need from "the agreements present in the state of the world". There is no way to "secure" subsections for tampering.

[riannella]

Sorry for chiming in late, but a fundamental question...

How do you what part (eg constaint) of an ODRL Agreement your SOTW assertions are about?

[joshcornejo]

@riannella - I already raised this as an example of the mapping between odrl:leftOperand and the different elements addressed (it is not the same source nor location for the :function / :target / :action / :constraint). In some cases (:function), they are not even explicit (e.g. the location of an assignee can be determined by the IP address, which is part of the payload and shouldn't be client-managed).

[AndreaCimminoArriaga]

Current model:

Modified model:

Proposal:

• I propose to remove the Constraint from the original model and have a RequestParameter instead used to express dynamic values that can be provided by a requester (for instance the DID) or by the system (the current datetime the exact moment before the enforcement).
• There is a potential issue that the RequestParameter should be linked somehow to the constraint of a specific policy. This could be addressed by adding an object property in the RequestParameter that points to the id of such constraint.

[AndreaCimminoArriaga]

Taking into consideration the previous proposal, I would like to present the following example to showcase different interesting aspects:

Scenario: whoever is a professor is allowed to enter his/her office if current timestamp is before 19:00 (it assumed door status must be closed)

ODRL EXTENSION

# Definition of custom action for this example
ont:openDoor a :Action, skos:Concept ;
	rdfs:isDefinedBy ont: ;
	rdfs:label "Open door"@en ;
	skos:definition "To open the door or a particular office"@en ;
	skos:note "As result an IoT smart lock receives the open/close order"@en ;

EVALUATION REQUEST

# In this case the person relies on DID for identification, therefore sotw:requestingParty is not needed
ex:request a sotw:EvaluationRequest ;
    dcterms:issued "2025-10-20T12:14:10.999Z"^^xsd:dateTime ;
    sotw:requestedAction ont:openDoor ;
    sotw:requestedTarget ex:door-office-33 ;
    sotw:requestParameter [
    	# Provided by requester
        a sotw:RequestParameter ;
        sotw:value "did:example:abc123"^^xsd:anyURI ;
        sotw:describesFeature sotw:DIDIdentity ;
    ],[
    	# Provided by the evaluator system when evaluation is received
        a sotw:RequestParameter ;
        sotw:value "2025-10-20T12:14:10.999Z"^^xsd:dateTime ;
        sotw:describesFeature sotw:TemporalData ;
    ] .

STATE OF THE WORLD

st:C12 a sotw:SotW;                             
   sotw:context st:C12Context-A, st:C12Context-B 
   sotw:action [ a ont:openDoor ] .

st:C12Context-A a sch:Person;
	sch:profession "Lecturer";
	sch:hasDID "did:example:abc123"^^xsd:anyURI ;
	sch:hasOffice ex:door-office-33, ex:door-office-34 .

st:C12Context-B  a saref:Device;
	saref:makesObservation [
		a saref:Observation ;
	    saref:observes ex:door-office-33 ;
	    saref:observes ex:door-office-33#openclose ;
	    saref:observes saref:OpenClose ;
	    saref:hasResult saref:Open ;
    ] .