<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
<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?
simon
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
+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.
phil
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
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
+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
+3
<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?
[crickets]
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
q/
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
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
<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.
<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...
<renato>
… 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
+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.
q/
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