See also: IRC log
<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
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
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.
"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