POE WG London F2F Day 2

19 May 2017

Meeting Minutes

<simonstey> https://‌iswc2017.semanticweb.org/

benws: we should prioritize the agenda items today

<victor> is there anybody scribing?

<renato> ODRL Validator = check for conformance of the policy that is meets the ODRL IM (spec) requirements

Agreed: start with the validation by an ODRL processor

<renato> ODRL Evaluator = determines whether the permissions and prohibitions of a policy are in effect

phila: a validator will check the syntax but should also check semantic quality
… by RDF terms this could/should be done by SHACL
… ODRL evaluator: has to check if the permissions/prohibitions are in effect

<renato> sound?

[sorry webex-ians, we have unplugged you]

<victor> (in the meantime, benws gave me the rationale for why the ODRL evaluator speaks in terms of permissions/prohibitions and not actions

<victor> ...which convinced me)

.... slow progress, but progress ...

[audio is back]

benws: the focus should be set on the permission/prohibition and the associted system should know what action it may take.

renato: if the specs talk about a "black box" we should call it ODRL validator

simonstey: an ODRL evaluator must cover all components required to check all parts of a policy

benws: the evaluator should only work with approved output of the validator.

renato: a "black box" should be part of the ODRL evaluator (corrected!)

phila: we should think about a "constraint checker" - could be software or a human - and it should reply to the evaluator.
… ODRL does NOT define how exactly how such a constraint checker should work, it should only return
… if a concept has been satisfied or not

ivan: better name for "black box" ?

benws: "constraint checker"

simonstey: "external constraint checker"

simonstey: checking Duty would be covered by checking a constraint

<phila> We have three conceptual units:

<phila> 1. An ODRL Validator that checks that the ODRL is correct.

<phila> 2. An ODRL Evaluator that determines whether or not a particular permission/obligation is in effect.

<phila> 3. A Constraint Checker. This is any system that is able to return a satisfied/not satisfied response when queried by the ODRL Evaluator

<phila> phila: Attempt 2

<phila> We have three conceptual units:

<phila> 1. An ODRL Validator that checks that the ODRL is correct.

<phila> 2. An ODRL Evaluator that determines whether or not a particular permission/obligation is in effect.

<phila> 3. A Constraint Checker. This is any system that is able to return a satisfied/not satisfied response to the ODRL Evaluator

All: phila's proposal is agreed

Discussion of how the workload of all the editing could be covered in the near future - including renato and serena

renato: they key work is to transform the conclusions of a meeting into wording for the specs

<simonstey> everyone should have a github account btw

renato: a key issue: what should be in the normative specs - the non-normative is less important

benws: we should should nail down the role of a profile

benws: asked simonstey : what would we lose if a profile may change everything (of ODRL)

simonstey: we would lose creditability - something my be called ODRL but almost everything may be changed!
… a profile may extend ODRL by variants of parties, actions ... and that's fine

benws: where to draw the line

simonstey: adding actions

Core and Profiles

<renato> https://‌w3c.github.io/‌poe/‌model/#constraint-compound

<simonstey> https://‌github.com/‌w3c/‌poe/‌issues/‌173

Discussion about: constraints on constraints

benws: on compound constraints: currenly only 1 level deep, what if a profile wants to extend this to three levels

simonstey: that raises an internoperability issue: should any ODRL processor support such an extende profile

benws: where should we stop profiles to change ODRL?


simonstey: this could be done by MUSTs in the specs

<phila> phila: +1 to Simon - no overriding of the core

benws: this should include cardinalities

<renato> "The left and right operands must both be Atomic Constraints."

benws: then we should be careful with using MUST in the specs

phila: if we agree that a profile cannot override what the specs tells - and if we want to cover that more tha 1 level of constraints is processed
… the specs should not use MUST for 1 level

<simonstey> +1 (was about to say what phil said)

phila: we sould also use SHOULD as it allows to override a spec in special and well reflected cases

benws: we should work on the specs and in a final review we should check all the used MUSTs - and may consider changing some to SHOULD

<simonstey> we should also add a respective disclaimer

<phila> PROPOSED: Profiles CANNOT overwrite the core model

<simonstey> +1

<benws> +1


<phila> +1

<renato> +1

Resolved: Profiles CANNOT overwrite the core model

renato: do we need a profile property, do we need that

victor: it identifies the profile, nothing else

<victor> the property odrl:profile is defined as: The identifier of an ODRL Profile that the Policy conforms to

benws: a processor should say "I dont' understand this profile"

<simonstey> This property is OPTIONAL, but if the property appears, then any consuming system MUST understand the identified ODRL Profile and all the constraints in the ODRL Profile MUST apply to the Policy expression. If a consuming system does not understand the ODRL Profile, then it MAY continue processing the Policy expression, but it SHOULD NOT assume it has interpreted the Policy expression correctly.

simonstey: raised: two sentences (see above) contradict each other

<phila> phila: simonstey speaks sense

benws: invited simonstey to suggest and changed wording

<simonstey> The conflict property MUST take one of the following values:

simonstey: another issue: the currently defined 3 conflicts must be covered by profiles, but it may add more items

<simonstey> https://‌github.com/‌w3c/‌poe/‌issues/‌172

<simonstey> s/"any consuming system"/"any consuming system that supports/implements given profile"/

renato: is the second sentence (see above) the better one?

simonstey: does not like the statement "any consuming system"

simonstey: if the specs say "one of these items MUST be used" then it should be still possible that a profile adds items.


phila: can a policy use more than 1 profile

benws: yes

phila: but what if the profiles are controversial

phila: cardinality is an area of potential conflicts

simonstey: it is the responsibility of the party applying policies to check if they conflict

phila: all applied profiles are of equal standing

benws: yes

phila: the ODRL validator must understand profiles and run validations against it

simonstey: this is not going to work

phila: a processor only understanding the core ODRL should be a fully valid one
… a processor doesn't have to understand all (existing) profiles

simonstey: if we would live only in the RDF world SHACL could help - but not all users of ODRL will be living there
… it would be good to have a standardized way to express additional constraints

<Zakim> phila, you wanted to annoy Stuart

<simonstey> +1

phila: should we require that an ODRL processor is able to work at the RDF level

simonstey: acting at the RDF level would help - e.g. using SHACL to understand a Thomson Reuters profile

benws: ok, this could be done by ODRL 3

<renato> https://‌github.com/‌w3c/‌poe/‌issues/‌173

<renato> 10 min break

<simonstey> https://‌tools.ietf.org/‌html/‌rfc8174

<simonstey> Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words

<renato> back

<benws> We're back

benws: we have resolved POE issue #173

renato: yes

<renato> @simon you need to add an issue to: https://‌github.com/‌w3c/‌respec/‌issues

normative vs non-normative in the specifications

benws: the normatie part should be as small as possible

benws: top level actions should include use and transfer - what else?

renato: all current actions are a narrower term of these two

benws: how does distribution fit into that?

renato: narrower term of use

Resolved: Use and Transfer are the only normative core Actions

<benws> +1


<renato> +1

<simonstey> +1

renato: any constraint leftOperands or operators in the core?

benws: no

renato: duty actions?

benws: sees no need

renato: compound constraint operands?

simonstey: example for "these operators MUST be supported" and more may be added

benws: supported that

<ivan> timing relationships?

<renato> If a Policy contains the dc:isReplacedBy property, then a processor must consider the first Policy invalid and must retrieve and process the identified Policy.

benws: a processor should know if a policy is in effect

renato: showed the only rule regarding that

<renato> https://‌w3c.github.io/‌poe/‌model/#provenace

simonstey: a time constraint could constrain the use of a policy

benws: but the internal processing of constraints is not controled by ODRL

phila: we should use well understood properties to express if a policy is in effect

<renato> The Rule determines the validity period

phila: if properties would define if a policy is in effect why not to use the same properties to tell if a rule is in effect

<simonstey> http://‌w3c.github.io/‌poe/‌vocab/#term-dateTime

benws: the ODRL core should not make any leftOperands mandatory - which is a conclusion from what was just said
… clarified: the constaint on a policy should only be about date/times

<renato> https://‌w3c.github.io/‌poe/‌model/#provenace

<renato> dc:time or odrl:time ;-)

phila: it is right that we include a set of optional policy level metadata terms and make normative statements concerning what an ODRL validator must do if such properties are present.
… any indiviual rule is only in effect if the policy is in effect

<renato> @ben https://‌www.w3.org/‌2016/‌poe/‌track/‌actions/‌22

victor: should some leftOperands be normative?

benws: may be widely used but should not be normative

victor: what about the Vocabulary document

michaelS: ... will be slim

<simonstey> and the mapping to xml/json?

renato: but many terms will go into the non-normative vocabulary

benws: normative terms should go into the ODRL Info Model document, the current Vocabular should be change to a non-normative NOTE document

victor: the ontology will be a non-normative document too?

ivan: we jump ahead here - these are editorial issues
… it is ok to define a small core, it is ok to define a basic profile, he sees no reason to make this profile not-normative
… why exactly should this vocab be not-normative.
… re editorial part: ok, to move core actions etc into the Info Model - but is this easy to read?

<renato> isn't that editorial?

ivan: Users will have more look into something like the Vocab document but not the Info Model
… not sure that all is a good idea.

<phila> +1 to Ivan

<renato> About 30 terms

victor: concludes: also the ontology has to be split into non-/normative

simonstey: wondering what it means to have a normative ontology - but what impact on the serializations XML, JSON ...

renato: we should have a normative Info Model and Vocabulary document and in addition a non-normative vocabulary document - as NOTE

phila: asked ivan if he is really against merging core vocabulary terms into the Info Model doc

ivan: yes, prefers to have a special Vocab document - even only with a few terms in it

<renato> https://‌www.w3.org/‌TR/‌annotation-vocab/#web-annotation-ontology

<simonstey> https://‌github.com/‌w3c/‌poe/‌issues/‌104#issuecomment-277964079

renato: shared a link to the Web Annotation Vocabulary - a kind of template?

victor: raised how to prove that an implementation complies with ODRL

<victor> +1 to renato proposal

Multiple replies: W3C trusts the providers of reports about success

renato: having a single vocuablary document with a mandatory and a non-mandatory parts

benws: would prefer to have explicit supports of profiles. At the time of the release of

<victor> -1 to having again a Creative Commons profile. I have seen no use of it in the past.

benws: ODRL a RightsML and a financial services sector profile will be available

renato: would prefer to have an open/common profile which would make use of terms from the non-mandatory vocabulary.
… it would be good to see if some vocab terms are adopted widely

ivan: leans towards renato's view

<renato> "common" vocab

<renato> "An ODRL Profile will directly serve the communities needs"

Discussion about the scope of profiles: for a wider audience or only for narrower special audiences

renato: proposed to call the non-mandatory terms as "ODRL common vocabulary"

<phila> michaelS: Did I get it right - having such a common vocab that there should be any ODRL supported feature implementing all these. It's a bag of terms I could use. Anyone can select it for his/her own profile. Individual profiles can be mixed withbthe common profile

<phila> michaelS: Common vocab or common profile?

<phila> benws: Common profile

<phila> michaelS: You proposed, renato, to call this a common vocabulary

<phila> renato: True. It's not trying to meet a particular community

<phila> ... So other people are encouraged to use these as they wish in *their* profiles

<phila> ... It's not really our goal to provide the business requirements for a specific sector

<phila> benws: But again... we've defined a very small core model. We have said how it can be enriched with further semantics, i.e. with a profile, so we shoujld do it

phila: undestands what benws wants to say
… but a common profile is not for a specific community

benws: this common profile should only show what can be done with profile

phila: who would use that common profile?

benws: people having first looks at ODRL

phila: if IPTC and W3C create a joint RightsML profile - what is its relationship to the common profile

renato: profiles should aim at people having a specific interest

phila: proposes to name it Generic Profile

<phila> PROPOSED: That the terms in the vocabulary, not in the normative core, be published as a generic profile

<renato> Split the current single Vocabulary section into two:

<renato> "4. ODRL Core Vocabulary" (normative)

<renato> "5. ODRL Generic Profile" (non-normative)

<simonstey> we then have to add odrl:profile statements to all examples in the IM that use actions != use/transfer

<phila> PROPOSED: That the terms in the vocabulary, not in the normative core, be published as the Generic Profile

<phila> acsk s

<phila> simonstey: We're talking about additional actions. When does the new profile start. Is Alice's Party a new profile now?

<phila> ... I need a profile to add new parties etc.

<phila> ... As R said what actually constitutes a profile?

<phila> ... We add new semantics, yes...

<phila> ... but how do you integrate the profile in your model.

<phila> simonstey: What does it mean that the profile is adding semantics?

<phila> benws: If we can it a core vocab or a core profile, does the issue go away?

<phila> benws: If we say, it's part of the core model, does the problem disappear?

<victor> simon:query

<phila> simonstey: I define a new action simon:query

<phila> ... I have to somehow magically integrate that into the core.

<renato> "If a consuming system does not understand the ODRL Profile, then it MAY continue processing the Policy expression, but it SHOULD NOT assume it has interpreted the Policy expression correctly""

<phila> simonstey: Currently I don't have to define my profile I can just use it in a policy

<phila> benws: And why does this change with profiles?

<phila> simonstey: My question is: what does a profile need to contain?

<phila> renato: This is what I asked - what is the purpose of the profile property?

<victor> (in fact current examples use terms from external vocabularies, like vcard)

renato: If I use the generic profile, so I now need to understand all the terms in the common profile?
… That'[s why I think it's a common vocabulary

<victor> I prefer common vocabulary over profile as well.

benws: So can I create a common vocab for exchange data rather than a profile for it
… And what's the difference between creating a profile and a vocab?

michaelS: I see the difference - if you create a processor that processes a profile, then all the features in the profile must be supported
… If we make the 25-30 actions in the generica profile, then a generic profile processor must understand them all.

benws: So if we don't make it a profile, then how will the processor deal with it. If we make the processor able to understand the common vocab, but it's not a profile, then what does it achieve [scribe paraphrase]

<simonstey> odrl:acceptProfile "simon"

benws: We can't guarantee that the processor will understand all the terms.

<simonstey> -> understand all terms with prefix simon:

michaelS: I consider the common vocab not as a profile but a grab bag of terms that can be used

<Zakim> phila, you wanted to talk about the generic profile being too big

<ivan> +1 to Phil

phila: Suggests that we create a profile from a subset of the common vocab

ivan: You're going one step too farm, Ben. If we have the common vocab, say profile A that uses 2 terms from the common vocab. The process that understands A doesn't need to understand all the terms in the vocab

benws: But does that mean that we#'re mandating the use of at least one profile?

<victor> +1 to Phil too...

michaelS: Only if they want to go beyond the core

benws: The core doesn't allow you to use ODRL in the real world

<victor> perhaps we want to hear Stuart's opinion in the next call

ivan: We have a core. We have a vocab with terms that people may or may not want to use. Industry X may, for example, choose terms from the generic vocab, call that profile A
… No problem

renato: I want to support... if we document how you would use the common vocab, then we need to do that and prove it.
… But the purpose is that you create a profile that might use some of the common terms

michaelS: I think it even more supports the requirement to use a profile.

ivan: To do anything for a spedcific industry there must be a profile

michaelS: And it would be good to have some examples

michaelS: We could invite the use case providers to create profile for their use case.

victor: I can provide the small policy on data. Where we need 7 or 8 terms.

<renato> Split the current single Vocabulary section into two:

benws: Great.

<renato> "4. ODRL Core Vocabulary" (normative)

<renato> "5. ODRL Common Vocabulary" (non-normative)

<renato> (latter used as a possible source for Profiles)

victor: There will be profiles that are not official

phila: (they don't need to be)

<victor> This is how we used ODRL to license linked data

<victor> http://‌purl.oclc.org/‌NET/‌ldr/‌ns#

victor: Talks through the doc ^^

phila: Clarifies that Victor can update his software to be conformant with ODRL new, with a profile that is a subset of the common vocab. That, alongside the AP use of Rights ML and TR's use of their own profile.

<renato> BRB..

phila: And that's your CR Exit Criteria met

<renato> back

<victor> you can the see the software running as a linked data server, see here: http://‌conditional.linkeddata.es/‌ldr/‌resource/‌Provincia/‌Valencia

<victor> (only for the record, not now obviously)

phila: DRAFTs

PROPOSED: That we will publish the non normative vocab terms as the 'ODRL Common Vocabulary' but *not* as a Profile.

PROPOSED: That we will create at least one profile from the Common Vocabulary and demonstrate its use in running code as one example of an ODRL implementation

<victor> ping

PROPOSED: That the vocabulary terms that form the Core Model will be published as normative elements in that Recommendation

PROPOSED: That the vocabulary terms that form the Core Model will be published as normative elements in that Recommendation

[Consensus to vote on all three]

<simonstey> in that rec. refers to what?

<ivan> +1 +1 +1 +1

<renato> +3

<michaelS> +1 +1 +1


<Sabrina> +1 +1 +1

<simonstey> +3

<renato> rec = "Vocab" document

<victor> +1.5 (weak accept, but have no other better proposal. Still cannot figure out the final form of the documents, ontologies, examples, bestpractices and which document references which one. I would be happy to see a diagram)

Resolved: That the vocabulary terms that form the Core Model will be published as normative elements in that Recommendation

Resolved: That we will publish the non normative vocab terms as the 'ODRL Common Vocabulary' but *not* as a Profile.

Resolved: That we will create at least one profile from the Common Vocabulary and demonstrate its use in running code as one example of an ODRL implementation

<renato> Late dinner ;-)

<victor> (this diagram will be anyway needed to illustrate these complex ideas to the ODRL readers)

<renato> Back at 1:15 London time

<michaelS> = 14:15 IRC time

<michaelS> kk

<renato> This is Brisbane...12 Points to....

[Resume after the break]

<Zakim> renato, you wanted to ask are the serialisations normative

<renato> https://‌w3c.github.io/‌poe/‌vocab/#encodings

<victor> (http://‌w3c.github.io/‌poe/‌vocab/#encodings

<simonstey> and xml?

ivan: The normative, is the RDF vocab, then there are standards to serialise it in (say, Turtle, triples etc.)
… But the RDF serialisations as JSON-LD etc. are not normative

ivan: 5.1 says RDF/OWL encoding - sorry, this is meaningless. It's RDF encoding, meaning in Turtle or JSON-LD and that's informative
… In 5.3 is also meaningless - we should just say that we provide the context file.

ivan: I don't know about the XML encoding

michaelS: What about the JSON encoding?

ivan: That's not in this doc for now
… I think we said that there's no need to have a separate JSON encoding as we have JSON-LD

renato: So... we can't just say section 5 is informative?

<simonstey> https://‌github.com/‌w3c/‌poe/‌issues/‌46

ivan: It depends on the XML

renato: I assume that the XML encoding is informative too

ivan: That's not what it necessarily means
… We may have to have some proven exchanges
… So you'd have something to ingest XML and process with same semantics as RDF
… If there's only one implementation of the XML then there's no need to make it normative.

simonstey: We have terms that are only there to support the XML serialisation
… It's not just about normative/not normative

renato: I think we have to mark section 5 as informative. Anyone disagree?

ivan: No, but, the RDF encoding is probably trivial from this point of view. Do we have to go through the XML encoding? Even if it's not normative, it should be correct.

renato: We should validate the XML
… It has been kept up to date with the schema
… I'm doing it as we go through

ivan: So in a sense, I'd say that section 5 should be only the XML encoding. The RDF and JSON encoding are empty sections

<victor> I find this asymmetry somewhat strange

ivan: You can say somewhere that there is a namespace and we provide a JSON-LD context file. And then section 5 just reduces to the XML encoding.

renato: So where would you put the note about the context file?

ivan: Do you not have a section with namespaces, conformance etc?

ivan: Is the ODRL namespace the only one we ever use or are there references to others

michaelS: Dublin Core

renato: OWL, SKOS etc.

ivan: There's a habit to list the namespaces used in the doc.
… And in that namespace, you add the info that the ODRL ontology is at X, context file is at Y etc.

phila: I'd just put the context file at the same place as the ontology and use conneg

ivan: No, they're different things

ivan: We need to make sure that all the changes in the doc are listed in the change log.
… Should be a change log since the latest publication
… The current version has been through horizontal reviews
… I have been bitten by later reviews in CR etc. when changes in docs were not properly described.

<victor> [about the past discussion: either in a section or not, I believe that besides the naked ontologies a few comments are needed on what is the ontology for, what is an ODRL expression in RDF and things of the sort ]

renato: I can work out from that bullet point list now what goes where.

renato: We had a few things on the agenda...
… we wanted to look at the 2 notes, the Exit Criteria, and the test suite
… Let's assume we've been through all the issues and made the changes
… We then to identify the exit criteria and the test suite lined up.
… Working through the 2 docs, I can see how they go, but what about the CR exit criteria?

ivan: It's a little more than that.
… We have to give clear and precise statements on when we consider that the period has proven that the spec is consistent and implementable and usable.
… It has to be clear, usually, for APIs, they have to be 2 independent implementations that produce the same output.
… Translate that to our case, and we have to define that in the doc itself. We have a number of text cases, we say how we measure success.
… Do we want to have at least 2 independent implementations/usage of the core technologies
… Showing that they're useful and ready to deploy.
… That shows that what we did was meaningful
… One more minor statement - if we have the exit criteria defined and documented - then we can transition a few weeks before the test suite is available.

renato: So with the work with OA, which looks related, what can we learn?

ivan: (looks for exit criteria statement)

<ivan> https://‌www.w3.org/‌TR/‌annotation-model/#candidate-recommendation-exit-criteria

ivan: I'm not sure that it translates exactly into this space

renato: That's a set of features that look like the mandatory parts of the IM
… A policy with a constraint, an agreement etc.

phila: The core is normative, most of the common vocab is not

<ivan> https://‌www.w3.org/‌TR/‌annotation-vocab/#candidate-recommendation-exit-criteria

ivan: For the OA vocab, we concentrated on...
… We have an abstract model that we translate into RDF, are we sure that the RDF ontology is consistent with the model.
… That needs testing
… That's where we focussed for Open Annotations
… Al our examples were JSON-LD, we transofmred it into Turtle and ran the tests. Something like that would be useful. It tests our own document.

<ivan> Examples for implementation reports https://‌w3c.github.io/‌test-results/‌annotation-model/‌all.html

<ivan> http://‌w3c.github.io/‌test-results/‌annotation-vocab/‌all.html

phila: Explains limited number of days to work on this after which I may or may not be on the team

[Discuss OA test suite created by Shane McCarron]

ivan: This is a lot of work.
… Given Phil's situation, I think someone else should take charge

renato: I agree
… We need dedicated effort and leadership on this task otherwise the 2 specs will fall.
… So can someone volunteer to take this on?

phila: Looks at simonstey ;-)

simonstey: I'm happy to work with someone on this. We're talking about having proved that something is used. But this is different from checking constraints using SHACL

simonstey: I'd tackle the thing from a tech perrspective
… We're open in how we define our test cases.

<victor> I agree with Simon, this is something difficult to assess.

simonstey: There's this aspect of checking whether a policy produced conforms to our requirementes

<renato> phila: test the validator and evaluator

ivan: I understand what simonstey says - we have to have an understanding of the whole CR is made for,
… Its primary purpose is to prove that the spec is consistent, implementable and useful.
… There may be instances of ODRL that express rubbish, but we can't check, nor do we have to.

<simonstey> https://‌github.com/‌simonstey/‌ODRL-SHACL-Shapes/‌wiki/‌SHACL-Shapes-for-validating-ODRL-Policies

ivan: We have to draw a line somewhere.

simonstey: I don't know how I'd tackle the XML side - nor do I have any inclination to test it.

ivan: If we are careful to make the XML non-normative, we don't have to test it. CR only tackles normative features.
… So for testing, we can forget about XML

simonstey: I'm also busy of course and I have to finish my PhD at some point. SO someone else would be helpful too.

<Zakim> phila, you wanted to ask about XML

phila: If XML is informative, can an XML-based implementation be adduced as evidence of ODRL implementation?


ivan: Our model is in RDF, and our serialisations in RDF have a bunch of standards already.

ivan: Ideally, you should be able to read in one of the RDF serialisations and do whatever you need with it, then there's no issue about doing stuff that doesn't conform to the vocab.

ivan: The implementation that we use for testing should be able to read in one of our RDF serialisations

renato: What tech will TR use?

benws: RDF

renato: Caroline says theirs is in JSON

victor: What we have is ODRL 2.1 so we need to update
… I can commit to updating docs but not software.

renato: That's why it's important to work on the test cases


michaelS: I'd like to suggest that today we list what needs to be done
… And then discuss on the next call

michaelS: We have to make some checks with WG members not present right now

victor: And having more test cases is important too.

<simonstey> https://‌github.com/‌simonstey/‌ODRL-SHACL-Shapes/‌wiki/‌SHACL-Shapes-for-validating-ODRL-Policies

benws: Once the test cases exist, then people can assess how much work is involved in implementing

benws: So what's left on the agenda?
… I'd like to hear about the formal semantics and best practices

renato: Yep.

renato: Simon has volunteered to work with Phil to get the test cases going and then if Phil goes we'll need someone else.

renato: We have some examples of how to do tests

<victor> https://‌www.w3.org/‌2016/‌poe/‌wiki/‌Best_Practices

Best Practices

victor: You'll see 16 examples from the spec. I need someone to look and review
… And is this the right format/structure

<simonstey> https://‌www.w3.org/‌TR/‌dwbp/ ? ;)

phila: Recent BP docs aren't relevant here (such as DWBP)

ivan: Jeni did a great job for CSV on the Web, but again, it's not the same kind of doc.

benws: How to make an offer (eg 7) - It needs a paragraph to introduce it.
… Policy Type etc. I'm happy to write those paragraphs.

ivan: All the examples are in JSON-LD

<simonstey> me2

ivan: I am probably like Victor, I prefer Turtle

Dataset Usage Vocabulary

<ivan> +1 to ben

benws: Back to Ivan's point about adding the paragraphs. Should we title these differently - it's written as if the reader already knows about ODRL. I think the titles shoujld be business issues that show ODRL solutions.

victor: Who is the reader of this doc?

benws: I think it's someone who has business problems and wants to see whether ODRL can solve them.

victor: Will there be a section in the UCR showing where each req is met?

phila: Normally the other way round. The Rec shows here the Reqs were met

ivan: Maybe take one or two examples from the BP doc, pref with real world data, show how the data is validated and evaluated.

ivan: Not for all of them - it's too much - but take a couple of examples.
… They could come from the UCR

victor: That's a lot of work

renato: Remember the use cases we got from BSIG/Bill K
… Can we look at some of those?

benws: Good idea.

renato: So, Victor, this you get this list by going through the IM?

victor: Yes.

benws: I'll go through some of the licences that we've already translated at TR and go through the BSIG stuff and between them we should have some good examples

victor: Is this for developers?

benws: No, it's I have business problems, does ODRL solve them? If so, how?

renato: And I assume this will be translated to a ReSpec doc on GH?

<renato> http://‌w3c.github.io/‌poe/‌bp/

benws: Will GH allow us to do the Turtle/JSON-LD Switch?

phila: It's a JS library

renato: Did Paul Jessop get back to you?

benws: No.

Formal Semantics

<simonstey> https://‌www.w3.org/‌2017/‌04/‌11-poe-minutes.html

simonstey: That's the one meeting we had ^^
… It w as primarily that we need to clarify what the FS doc should cover.
… We left it out today. It only makes sense if there's something like conflict management. You need something more precise than natural language.
… We didn't talk about whether an evaluator should merge policies
… The black box Constraint Checker helps
… we'll need further discussions of course.

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

simonstey: The scope of the FS document... Ivan looked at my paper. Very helpful
… He also said that there is a fine line between being too abstract and being too informal

simonstey: Taking this paper as the basis, might be too much

simonstey: I think we should be clear what we expect from the FS document
… For the validation part, then the SHACL files don't need guidance, but for evaluation, you do.

benws: There are 3 use cases I'd find useful

benws: One s where a supplier creates an agreement policy with us, and then they use a Next Policy that allows our customers to use their info that we're distributing.
… We will then go and create a new agreement with out customers, but we need to check that our policy is consistent with the one given by our supplier.

<Sabrina> interesting usecase Ben.....

simonstey: This is interesting
… That's not covered by the IM
… There's nothing about policy merging in there
… We have policy conflicts
… The approach would be you take all the rules from one policy and put it in another.

simonstey: I've brought up a few times - we still don't have a concept in the IM to relate actions to each other. There is no property to relate one action to another, saying it's a broader or narrower term
… Without that, it boils down to a specific action - is it allowed or not?

benws: But the common vocab will give us that hierarchy of actions

simonstey: I think this is super important for the IM (Antoine Isaac raised it)

benws: How should you represent them?

Sabrina: You have an arc saying broader or narrower

benws: Do we use SKOS to do that? SubTyping?

simonstey: We have neither currently

simonstey: What effect might this have on XML?

benws: Can we punt that?

renato: It's not an issue, XML can just use a URI
… But we have decided that it's informative...

… skos:broaderTransitive odrl:use ;

renato: It's not in our remit to explain how to use XML

benws: Do we want to support hierarchies of actions?

<Sabrina> +1 hierarchies in general

simonstey: Yes, on actions, but we can do more

simonstey: Primarily it's about relating actions to each other.
… My interpretation is that if there is a permission to use but a prohibition to read, and no conflict defined, then no conflict is detected. But if read is a sub action of use, there is

PROPOSED: That hierarchies be expressible between actions

victor: I have witnessed endless discussions about this and people may not agree.

benws: They'll be defined in profiles

<Sabrina> We should not define the hierarchy.....

simonstey: Yes. We say how to do it.

<simonstey> +1

<Sabrina> We just need the ability to generate hierarchies

simonstey: If the hierarchy is defined then a conflict may be detected. If no hierarchy, then there's no conflict

benws: I know I'll spend a lot of time discussing this here

<ivan> +1

ivan: Just for my understanding - in the model, we give some means to express this hierarchy, which is then normative and therefore testable.

victor: You can imagine that selling is a type of distribution... [sorry lost this]

PROPOSED: That hierarchies be expressible between actions

<ivan> +1

<renato> +1

<benws> +1

<simonstey> +1

<Sabrina> +2

<Sabrina> lol

<victor> two relations: "selling is a type of distributing" and "editing" implies "rendering".

<michaelS> +1

Resolved: That hierarchies be expressible between actions

<victor> +1

ivan: So how do we express this...

benws: Are we talking about one or two hierarchies?

<renato> skos:narrower?

victor: One is inheritance, and the other is relationships

<Sabrina> one is inheritance and another is a dependency

simonstey: We don't have to define those, we just have to facilitate it. Editing implies rendering etc.

<victor> simply declaring a new property called hasNecessaryAction

<victor> requiredAction

ivan: For me, the basic question is - do we want to have ODRL-specific ways to express this or so we want to rely on an external thing (skos, subClass)

<Sabrina> we should have to look at the semantics of the other vocab

ivan: skos:narrower has a clear description of what it means. Sub property has a very specific meaning. Are either what we weant to express

simonstey: If we introduce our own properties, then we have the formal semantics to define what those semantics are.

simonstey: If you rely on sub* then we would be fine saying just look it up.

ivan: But the question is whether the formal semantics of RDF impose things we don't want?

simonstey: Not if we had our own property

ivan: Indeed. But if we rely on rdfs:subProperty

ivan: I'm not sure we want that

simonstey: I agree

<simonstey> https://‌aic.ai.wu.ac.at/~polleres/‌publications/‌stey-poll-2015RuleML.pdf

<simonstey> section 3.1

<Sabrina> Shouldn't this be usecase driven?

PROPOSAL: We support two hierarchies: requires and inheritance

PROPOSAL: We support hierarchy with two properties - requires and inheritance

PROPOSAL: We support hierarchy with two properties - requires and narrows

<simonstey> +1

<ivan> +1

<victor> +0.5 (aware of the endless discussions it may generate, and aware of the incompleteness of having only two types of relations and no more)

<michaelS> +1 requires, -1 narrows

[Further discussion around sharing as example of requiring permission to distribute]

renato: So one permission leads to two permissible actions

simonstey: odrl:use. If I prohibit use, but I permit copy, then there are 2 things. You can't use it but you can copy it. That's a conflict.

ivan: Doesn't 'requires' cover that?

simonstey: [mumble] yeah

ivan: So why do we need 2

ivan: If we have an expression to relate 2 actions in one direction, why have 2?

simonstey: I started from the ODLR ontology

michaelS: If the hierarchy defines use as top level and present at a lower level and print even lower. If you want to print, if your policy permits use, then it permits print

ivan: I can express that with requires

michaelS: This is tricky. If you want to print, what does 'requires present' mean?

ivan: If there is no other rule, OK. But if there is, there may be a conflict and this detects it.

michaelS: Hearing the proposal about requires...

renato: So you can go across the hieracrhy, not necessarily up

simonstey: At the time I need to know, I have t check whether the permission that is required is also there, or, if absent, then I can proceed.

benws: In that discussion... did you agree that we only need one hierarchy?

ivan: I think 1 is enough

simonstey: I agree, 1 is enough

benws: It's the nature of that relationship that we're discussing

benws: Do you agree that we need one relationship?

<simonstey> transitive closure

michaelS: Yes... if you have this hierarchy, a broader action permitted, then you may also take a narrower action.

benws: Are the three of you now in agreement.

simonstey: There may be share and distribute but they're not in a hierarchy

michaelS: SO this goes across the hierarchy
… If you have a broader action permitted then you may take the narrower one.

benws: And is it the only relationship wew need

ivan: For the use cases I have heard,, yes.

victor: I don't think we should be discussing this. A light weight ontology - we've discussed enough. Or if we need a full thing then it'll take another day.

benws: It sounds as if we just need one single relationship

<renato> +1 to single relationship "narrow"

Sabrina: I see the need for requires
… Not allowed to use something but I am allowed to print. OK, but broader/narrower - it usually makes it easier to specify permissions, but instead of enumerating them, you grant at a higher level

benws: Is the broader/narrower needed for the FS or is it requires

simonstey: You need both

[Repeat discussion]

benws: I thought Ivan was saying e only need one

Sabrina: He was asking a question, not making a statement.

ivan: We started with a formal semantics discussion - there may be conflicts and these have to be handled somehow.

ivan: What you describe, Sabrina, is not the same
… Wwe're mixing 2 differnet things.

<simonstey> +1 to what ivan said

ivan: The narrower relationship is a convenience one, but requires is different and we shouldn't mix them.

michaelS: I try to figure out 3 cases

<simonstey> http://‌w3c.github.io/‌poe/‌model/#conflict

michaelS: We have present as broader than print and display. if the policy incl a permission to present and a prohibition to print, then display is still permitted.

<simonstey> prohibit: the Prohibitions MUST override the Permissions

<simonstey> perm: the Permissions MUST override the Prohibitions

michaelS: The broader term is permitted and so are the narrower ones, unless prohibited.

michaelS: Other way round... you have permission to print but prohibition to present. Present wins and you can't print.

<simonstey> in the profile

<simonstey> no

michaelS: Third is requires. There it is sufficient to have permission to present print and display. Is it sufficient to be defined in a linked profile or inside a spedcific policy?

<simonstey> no

<simonstey> not prohibited

michael: The requires - what does that mean - that the required action is explicitly permitted?

[Scribe error, previous statements by Michael, not Simon]

simonstey: Summarises
… Can say invalid if any conflict, then the permission to share and the distribute all invalid.

michaelS: Shouldn't we say "must not be prohibited"

simonstey: That's along property name

michaelS: But the semantics are better

simonstey: There are no semantics in a term name
… I'm not in favour of a term name 40 characters long

<victor> Action herarchies are not new in old ODRL. Please see Fig.2 in https://‌www.w3.org/‌TR/‌odrl/ (W3C Note, ODRL version 1.1)

<trackbot> Error finding 'herarchies'. You can review and register nicknames at <https://‌www.w3.org/‌2016/‌poe/‌track/‌users>.

victor: Let me remind you about ^^ figure 2

victor: Very old

<renato> What a great looking figure ;-)

victor: Do we need to discuss more of relevance today?

benws: It would be good to make progress so that Simon can begin work

victor: The actions that generate a new asset are worth looking at, as is next Policy

renato: I'd like to understand... narrower I understand... but what's the actual use case for requires?

simonstey: In the paper, again, share/distribute - there must be a conflict

renato: But isn't that a poorly defined action?

simonstey: You can define your default policy behaviour... maybe that it applies to everyone and then specific ones that allow you make exceptions

renato: We had a similar discussion around distribute. That also includes the ability to copy.

<Sabrina> yes....

renato: My response is - if you need both - if distribute can include copy...

benws: It's getting too complicated

<Sabrina> in my mind distribute and copy are autonomous - but some may argue both have the root of use

<renato> :-)

<victor> Summary. Actions are related to actions in two manners: specializeAction and requireAction. "sell specializeAction distribute" (it is a subtype) whereas "distribute requireAction copy" (you can't distribute something if you can't copy it). Both have impact on the authorization decision. 1. If you grant the permission to distribute, you grant any action that is a subtype of distribution (sell, lease) 2. If you grant the permission to distribute, you also grant[CUT]

<victor> ermission to copy, because you can't distribute without copying.

benws: It sounds as we need both to support the use cases

<simonstey> both are transitive

<Sabrina> lol

PROPOSED: That we introduce 2 properties that (whatever their names) mean transitive 'narrower' and 'non-transitive requires'

<renato> yes you can....I gave you 1000 copies to distribute

PROPOSED: That we introduce 2 properties that (whatever their names) mean transitive 'narrower' and 'requires'

PROPOSED: That we introduce 2 properties that (whatever their names) mean transitiv 'narrower' and 'requires'

<simonstey> +1

PROPOSED: That we introduce 2 properties that (whatever their names) mean 'narrower' and 'requires'

<simonstey> +1

<benws> +1


<Sabrina> +1

<ivan> +1

<renato> +0.49

<Sabrina> silence is taken as agreement

<Sabrina> :)

<victor> +0.5

<michaelS> narrower +1, "requires" -1

<victor> (conscious that we are possibly unleashing a monster: you see? renato challenged my statement that no distribution was possible without copy. and he was right!)

<renato> Yup :-)

<renato> Atomic actions are better option

PROPOSED: That we introduce 2 properties that (whatever their names) mean a hierarchical relationship and a non-hierarchical relationship between actions

victor: Expresses concern...

benws: Satisfies

PROPOSED: That we introduce 2 properties that (whatever their names) mean a hierarchical relationship and a non-hierarchical relationship between actions

renato: I'm happy with consensus with my vote

Resolved: That we introduce 2 properties that (whatever their names) mean a hierarchical relationship and a non-hierarchical relationship between actions

<michaelS> +1

<benws> +1

ivan: How to we express that - an extra triple between two actions? Where does it appear?

<simonstey> odrl:present odrl:narrower odrl:use .

<victor> exactly.

ivan: So this is something that a profile could include

<victor> in the ontology we have skos:broaderTransitive

<victor> already!!

victor: We already have SKOS narrower etc. in the actions ontology

benws: Yes, but it's not in the IM. It needs to be so that we can include it in the FS

<victor> to be more precise, we have skos:broaderTransitive

<renato> :grantUse skos:broaderTransitive odrl:use ;

<Sabrina> we need to check the semantics

<simonstey> we buy in their semantics

benws: The question is - do we use existing relationships (ie skos:narrower) or define our own

ivan: SKOS defines it in its own way. Our semantics are a little different.

<Sabrina> if their semantics matches our need then we will reuse, otherwise we come up with a new term

ivan: If, as I believe, we need our own semantics, then we should not use SKOS

<simonstey> https://‌aic.ai.wu.ac.at/~polleres/‌publications/‌stey-poll-2015RuleML.pdf

ivan: The semantics are very specific

<renato> :grantUse a :Action, skos:Concept ;

benws: SKOS is not a conflict resolution vocab, and this is

ivan: It's different

renato: We use SKOS throughout the ontology so far

simonstey: We define policy inheritance in a specific way
… Which is why we have our own inherit from.

renato: The community may want us to use SKOS...
… Is it not the common way?

ivan: No because SKOS just relates terms to one another but there are no additional semantics
… It's designed for concepts in library hierarchies etc.
… This is abstract entities

benws: We have had to tidy up the slack semantics in ODRL before now. I think we should use our own term, it's not the same as SKOS.


benws: We're talking about what action requires another action, not about terms

ivan: My understanding is that the hierarchy also includes consequences for the evaluators

phila: Makes a plea for a different name that just 'narrower' - suggest 'narrowerAction' etc.

renato: OK, but Serena and I need to know what we are to do.
… We'll have to remove SKOS from the ontology

ivan: Yes, but it's necessasry [Paraphrase]

michaelS: Doesn't this mess up having Use and Transfer as the top level actions

simonstey: Those top level ones are required so that you can relate the terms in your profile to the core.

Sabrina: I don't want to complicate, but... we've been focussed on actions but the same applies to assets
… What if I'm not allowed to print the Harry Potter book, but I am allowed to print the table of contents

benws: We discussed being able to apply constraints to assets that, we hope, will cover this.

Sabrina: That still might lead to a conflict.
… A blanket you can't print may or may not be overridden by the constraint.

Sabrina: It sounds similar to our discussion on the actions but I'll think some more.

PROPOSED: That we introduce the terms narrowerAction and requiresAction to the Information Model

Sabrina: We have to decide the scope of this. Does it only apply to actions. If we agree here then we'll have to repeat the whole discussion around Assets.

benws: So... we decide whether we apply the same conflict resolution to assets.

benws: explains the mechanism we discussed yesterday to impose constraints on assets

Sabrina: describes a conflict regarding permissions on a book, and one of its pages

simonstey: the preference between permission and prohibition can be expressed, but this mechanism does not solve all the cases

renato: may make sense, but then odrl is growing and growing.

benws: we at Thomsom Reuters want ODRL for compliance

small comment: narrowerAsset is strange; in any case I would term it partOf.

(phila is back)

phila: we spoke yesterday about Collections and scope

phila: how will the semantics will handle constraints on collections?

simonstey: this has to do with policy merging.

simonstey: the ultimate goal is to grab every possible aspect that might be relavant for the conflict detection.

simonstey: like actions might have other dependencies, etc.

benws: so you are talking about two properties, essentially the same across assets, actions and parties. Can these be summarized within two single properties?

Sabrina: can be the same property

Sabrina: although it can be done outside

<phila> PROPOSED: That we introduce the terms odrl:narrowerThan and odrl:alsoRequires to the Information Model

benws: shall we vote this?

<ivan> +1

<simonstey> +1

benws: provided that they apply to assets, actions and parties

<phila> PROPOSED: That we introduce the terms odrl:narrowerThan and odrl:alsoRequires to the Information Model. These are applicable to Assets, Parties and Actions

<simonstey> +1

<benws> +1

<ivan> +1

<Sabrina> +1

<phila> +1

Resolved: That we introduce the terms odrl:narrowerThan and odrl:alsoRequires to the Information Model. These are applicable to Assets, Parties and Actions

<renato> +0.9

<michaelS> narrowerThan +0.75, alsoRequires 0

+0.5 (not this wording, and unsure that an umbrella term can satisfy them all. Also unsure that this should be in the core).

<phila> S/RESOLUTION: That we introduce the terms odrl:narrowerThan and odrl:alsoRequires to the Information Model. These are applicable to Assets, Parties and Actions//

<renato> and defined !!!

benws: why dont we ask sabrina and simon to provide a document explaining this in detail?

ivan: the document should also include the English definition of the meaning.

Action: simonstey to send e-mail with relevant text for IM describing the new relationships narrower and requires

<trackbot> Created ACTION-44 - Send e-mail with relevant text for im describing the new relationships narrower and requires [on Simon Steyskal - due 2017-05-26].

benws: a presentation would be great in the next call.

Sabrina: I would like to be there, but I will not be present in the next call

phila: we should identify the next work items that we have ahead

phila: it would be nice having a further F2F meeting

victor: I would like to see a diagram with the relation between profiles, documents, namespaces, etc.

renato: I can prepare a first version

benws: AOB? I think we have finished.

benws: thanks to all

<renato> Thanks TR ;-)

bye bye

Resolved: Thanks to Ben and TR for hosting the meeting

Summary of Action Items

  1. simonstey to send e-mail with relevant text for IM describing the new relationships narrower and requires

Summary of Resolutions

  1. Profiles CANNOT overwrite the core model
  2. Use and Transfer are the only normative core Actions
  3. That the vocabulary terms that form the Core Model will be published as normative elements in that Recommendation
  4. That we will publish the non normative vocab terms as the 'ODRL Common Vocabulary' but *not* as a Profile.
  5. That we will create at least one profile from the Common Vocabulary and demonstrate its use in running code as one example of an ODRL implementation
  6. That hierarchies be expressible between actions
  7. That we introduce 2 properties that (whatever their names) mean a hierarchical relationship and a non-hierarchical relationship between actions
  8. That we introduce the terms odrl:narrowerThan and odrl:alsoRequires to the Information Model. These are applicable to Assets, Parties and Actions
  9. Thanks to Ben and TR for hosting the meeting