POE formal semantics discussion

<scribe> scribe: victor

victor launches the question: "what is the scope of the Formal Semantics Note"?

making reference to the document sent on the 27th of March.

simon: victor has proposed 5 reasoning tasks
... the validator is related to the test suite.

victor: there are at least three possible ways of implementing this

simon: everybody should be able to validate that the ODRL expressions they write are valid
... thinkgs like "has no assignee" etc. should be flagged
... there are syntactic constraints to validate (maybe SHACL maybe TestCases in a custom-made implementation)

ivan: the test suite is a must. But there should be an external validator, something like SHACL or similar so that testing software is not done by hand.
... from the three mentioned options (SHACL/SWRL/FOL) I prefer the first one if the things settle down.
... SWRL and FOL could be used but having SHACL, these options look more complex.

simon: we need an "invalid" class (victor: not attribute?)
... we need to define these constraints first, abstractly, independently on how the validating software runs.

ivan: +1

simon: we can start this activity actually now

ivan: ok

sabrina: I would also focus on "what we have to do". We have to validate not only the syntax but also the model.

all: yes

victor: the word Syntactic in the document is an evident typo

transformation between serializations

simon: ODRL users using XML/JSON have agreed to use the XML and JSON-LD serialization of RDF respectively

victor: if this is the case, we dont need transformation software at all :)
... is it of any value what has been done in other W3C Specs?

ivan: not really

sabrina: in any case, transformations can be made to a single syntax all-to-one and one-to-all

simon: regardless the transformation software, having an abstract syntax is stuff for a "formal semantics" note

victor: agree

The profiler

victor: a profiler tells you which profiles are being used, given a piece of ODRL

ivan: perhaps this is also SHACL, so this would be a part of the validator

simon: Profiles may allow "breaking the model", like for example having constraints out of any permission. Then, RDF shapes would be great.

satisfiability checker

"whether a odrl policy can be satisfied" given a set of policies.

simon: this is strongly related to the authoriser.

ivan: is this fundamentally different than "use an OWL reasoner" on the combination of policies and actions?

simon: i have implemented this authoriser in the past facing problems beyond the OWL representative power. I used
... the authoriser is something to be discussed within the entire W3C Working Group.

victor: +1

simon: https://aic.ai.wu.ac.at/~polleres/presentations/20150325NORMAS_Linked_Data_Policies_in_ODRL.pdf Towards Formal Semantics for ODRL Policies

<simonstey> http://link.springer.com/chapter/10.1007%2F978-3-319-21542-6_23

ivan: why not with SPARQL queries? using SPARQL as a FOL engine.

simon: well, this is in SHACL too.
... One example on dates. where is the property value I have to check against?

victor: in order to have an authorisation system we need to have an architecture with something called "context", telling you which is the age of the user, today's date, etc.

sabrina: this is the same as in other policy languages
... +1

ivan: I am afraid that this introduces complexity

simon: and also, many of the constraints will never be able to be validated

<Sabrina> +1 for the blackbox

ivan: where do we go from here?
... except writing a custom designed checker, what can we do?

simon: under the assumption that some duties/constraints can be fulfilled or not (and validated by a blackbox) we can describe the authorisation check. also we can tackle the merging policies with a conflict resultion strategy

victor recalls the work of OASIS XACML and the good precedent it created, but he thinks that support from the rest of the W3C Working Group is important.

<simonstey> http://link.springer.com/chapter/10.1007%2F978-3-319-21542-6_23

victor and sabrina agree.

ivan: skeptical about the readers of the documents

victor: there are two activities discussed today: (1) writing SHACL shapes for validation (2) Formal semantics for several purposes (conflict detection, merging policies)

ivan: we can decide that later.

sabrina: they are useful, wherever they are published

ivan: we have to communicate to the group, we have to schedule a workplan

simon: there are hidden constraints in the language which needs to be identified.

victor: why dont we open a wiki to work togethere?

simon: wikis are easier to maintain
... before the meeting of may we can start moving from the paper to html and adapting to the new situation

ivan: are you saying that we have to identify constraints in the text that need to be formalized?

simon: yes

ivan: if we had that list.... ...should that list be part of the normative spec?
... as part of the vocab document we may want to have a normative appendix referring to that list.

simon: similar approach was followed in SHACL
... the PROV group does the same with a single document devoted to constraints.

ivan: we have to report to the group

victor: right now? can't we wait until we have results?

ivan: what is the effort to reach that list?

simon: there are many vaguely defined things that needs to be fixed first. we have many github issues already....
... we need Renato's expertise and external feedback. this can take long.
... please think of relation/target and how the specificities of the UML model is having impact on the RDF representation

ivan: the normative text should be full-proof before we reach CR

simon: launches his concern on the spec to be precise enough

ivan: urges simon to make this thought public in the next call