07:26:35 <RRSAgent> RRSAgent has joined #poe
07:26:35 <RRSAgent> logging to http://www.w3.org/2017/05/19-poe-irc
07:26:37 <trackbot> RRSAgent, make logs public
07:26:37 <Zakim> Zakim has joined #poe
07:26:39 <trackbot> Zakim, this will be
07:26:39 <Zakim> I don't understand 'this will be', trackbot
07:26:40 <trackbot> Meeting: Permissions and Obligations Expression Working Group Teleconference
07:26:40 <trackbot> Date: 19 May 2017
07:26:49 <renato> RRSAgent, make logs public
07:27:13 <renato> Agenda: https://www.w3.org/2016/poe/wiki/Meetings:London2017
07:27:19 <renato> present+ renato
07:27:27 <renato> Chair: renato/ben
07:27:59 <renato> RRSAgent, draft minutes
07:27:59 <RRSAgent> I have made the request to generate http://www.w3.org/2017/05/19-poe-minutes.html renato
07:31:55 <renato> RRSAgent, draft minutes v2
07:31:55 <RRSAgent> I have made the request to generate http://www.w3.org/2017/05/19-poe-minutes.html renato
07:56:55 <ivan> ivan has joined #poe
07:57:18 <simonstey_> simonstey_ has joined #poe
08:00:54 <phila> phila has joined #poe
08:01:26 <phila> agenda: https://www.w3.org/2016/poe/wiki/Meetings:London2017#Friday_19_May
08:02:12 <renato> All ok there PhilA?
08:04:07 <renato> ok
08:08:07 <michaelS> michaelS has joined #poe
08:10:35 <michaelS> present+
08:10:39 <benws> benws has joined #poe
08:11:12 <victor> victor has joined #poe
08:11:19 <victor> present+ victor
08:11:25 <michaelS> scribe: michaelS
08:11:31 <michaelS> scribenick: michaelS
08:11:58 <phila> meeting: POE WG London F2F Day 2
08:12:04 <phila> present+
08:12:20 <ivan> present+
08:13:34 <simonstey> present+
08:14:00 <benws> present+
08:22:12 <simonstey> https://iswc2017.semanticweb.org/
08:23:58 <michaelS> benws: we should prioritize the agenda items today
08:25:14 <simonstey> +q
08:25:17 <victor> is there anybody scribing?
08:25:34 <renato> ODRL Validator = check for conformance of the policy that is meets the ODRL IM (spec) requirements
08:25:34 <michaelS> Agreed: start with the validation by an ODRL processor
08:25:42 <renato> ODRL Evaluator = determines whether the permissions and prohibitions of a policy are in effect
08:26:19 <michaelS> phila: a validator will check the syntax but should also check semantic quality
08:26:48 <michaelS> ... by RDF terms this could/should be done by SHACL
08:27:14 <benws> q?
08:28:12 <michaelS> ... ODRL evaluator: has to check if the permissions/prohibitions are in effect
08:28:20 <renato> sound?
08:28:40 <michaelS> [sorry webex-ians, we have unplugged you]
08:29:09 <victor> (in the meantime, benws gave me the rationale for why the ODRL evaluator speaks in terms of permissions/prohibitions and not actions
08:29:22 <victor> ...which convinced me)
08:30:09 <michaelS> .... slow progress, but progress ...
08:30:49 <simonstey> q?
08:30:51 <michaelS> [audio is back]
08:31:48 <simonstey> q?
08:31:51 <michaelS> benws: the focus should be set on the permission/prohibition and the associted system should know what action it may take.
08:32:30 <simonstey> q?
08:32:58 <michaelS> renato: if the specs talk about a "black box" we should call it ODRL validator
08:33:22 <phila> ack s
08:34:16 <michaelS> simonstey: an ODRL evaluator must cover all components required to check all parts of a policy
08:35:55 <michaelS> benws: the evaluator should only work with approved output of the validator.
08:36:53 <benws> q?
08:37:59 <phila> q+
08:38:05 <ivan> q+
08:38:25 <michaelS> renato: a "black box" should be part of the ODRL evaluator (corrected!)
08:39:21 <michaelS> phila: we should think about a "constraint checker" - could be software or a human - and it should reply to the evaluator.
08:39:35 <simonstey> +q
08:40:13 <michaelS> ... ODRL does NOT define how exactly how such a constraint checker should work, it should only return
08:40:17 <phila> q-
08:40:21 <michaelS> ... if a concept has been satisfied or not
08:40:27 <simonstey> q-
08:40:38 <phila> ack i
08:41:01 <michaelS> ivan: better name for "black box" ?
08:41:08 <michaelS> benws: "constraint checker"
08:41:18 <michaelS> simonstey: "external constraint checker"
08:42:26 <michaelS> simonstey: checking Duty would be covered by checking a constraint
08:43:21 <phila> We have three conceptual units:
08:43:21 <phila> 1. An ODRL Validator that checks that the ODRL is correct.
08:43:21 <phila> 2. An ODRL Evaluator that determines whether or not a particular permission/obligation is in effect.
08:43:21 <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
08:43:58 <phila> phila: Attempt 2
08:43:59 <phila> We have three conceptual units:
08:43:59 <phila> 1. An ODRL Validator that checks that the ODRL is correct.
08:43:59 <phila> 2. An ODRL Evaluator that determines whether or not a particular permission/obligation is in effect.
08:43:59 <phila> 3. A Constraint Checker. This is any system that is able to return a satisfied/not satisfied response to the ODRL Evaluator
08:44:47 <benws> q?
08:44:57 <michaelS> All: phila's proposal is agreed
08:46:29 <michaelS> Discussion of how the workload of all the editing could be covered in the near future - including renato and sabrina
08:47:04 <michaelS> renato: they key work is to transform the conclusions of a meeting into wording for the specs
08:47:08 <simonstey> s/sabrina/serena
08:47:24 <simonstey> everyone should have a github account btw
08:48:06 <michaelS> renato: a key issue: what should be in the normative specs - the non-normative is less important
08:48:44 <benws> q?
08:48:53 <michaelS> benws: we should should nail down the role of a profile
08:49:05 <simonstey> +q
08:50:07 <michaelS> benws: asked simonstey : what would we lose if a profile may change everything (of ODRL)
08:50:38 <michaelS> simonstey: we would lose creditability - something my be called ODRL but almost everything may be changed!
08:51:25 <benws> q?
08:51:32 <benws> ack s
08:51:37 <michaelS> ... a profile may extend ODRL by variants of parties, actions ... and that's fine
08:52:00 <michaelS> benws: where to draw the line
08:52:30 <michaelS> simonstey: adding actions
08:52:40 <phila> Topic: Core and Profiles
08:53:39 <renato> https://w3c.github.io/poe/model/#constraint-compound
08:53:45 <simonstey> https://github.com/w3c/poe/issues/173
08:53:55 <michaelS> Discussion about: constraints on constraints
08:54:24 <benws> q?
08:54:24 <michaelS> benws: on compound constraints: currenly only 1 level deep, what if a profile wants to extend this to three levels
08:56:01 <michaelS> simonstey: that raises an internoperability issue: should any ODRL processor support such an extende profile
08:56:31 <phila> q+
08:56:44 <michaelS> benws: where should we stop profiles to change ODRL?
08:56:47 <michaelS> simon
08:56:53 <phila> q-
08:57:03 <michaelS> simonstey: this could be done by MUSTs in the specs
08:57:04 <phila> phila: +1 to Simon - no overriding of the core
08:57:13 <michaelS> benws: this should include cardinalities
08:57:18 <phila> q+
08:58:32 <renato> "The left and right operands must both be Atomic Constraints."
08:59:08 <michaelS> benws: then we should be careful with using MUST in the specs
09:00:20 <michaelS> 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
09:00:33 <michaelS> ... the specs should not use MUST for 1 level
09:00:54 <simonstey> +1 (was about to say what phil said)
09:01:22 <michaelS> phila: we sould also use SHOULD as it allows to override a spec in special and well reflected cases
09:02:42 <michaelS> 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
09:03:03 <simonstey> we should also add a respective disclaimer
09:03:28 <simonstey> +q
09:03:40 <phila> q-
09:04:05 <phila> PROPOSED: Profiles CANNOT overwrite the core model
09:04:12 <simonstey> +1
09:04:15 <benws> +1
09:04:20 <michaelS> +1
09:04:22 <phila> +1
09:04:23 <renato> +1
09:04:34 <phila> RESOLUTION: Profiles CANNOT overwrite the core model
09:05:04 <michaelS> renato: do we need a profile property, do we need that
09:05:56 <michaelS> victor: it identifies the profile, nothing else
09:06:09 <victor> the property odrl:profile reads is defined as: The identifier of an ODRL Profile that the Policy conforms to
09:06:24 <michaelS> benws: a processor should say "I dont' understand this profile"
09:06:28 <victor> s/reads//
09:06:57 <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.
09:07:55 <michaelS> simonstey: raised: two sentences (see above) contradict each other
09:08:02 <phila> phila: simonstey speaks sense
09:08:40 <benws> q?
09:08:47 <michaelS> benws: invited simonstey to suggest and changed wording
09:09:15 <simonstey> The conflict property MUST take one of the following values:
09:10:01 <michaelS> simonstey: another issue: the currently defined 3 conflicts must be covered by profiles, but it may add more items
09:11:17 <simonstey> https://github.com/w3c/poe/issues/172
09:11:19 <renato> can u hear me?
09:11:37 <phila> s/can u hear me?//
09:12:23 <simonstey> s/"any consuming system"/"any consuming system that supports/implements given profile"/
09:12:47 <michaelS> renato: is the second sentence (see above) the better one?
09:13:10 <michaelS> simonstey: does not like the statement "any consuming system"
09:14:25 <michaelS> simonstey: if the specs say "one of these items MUST be used" then it should be still possible that a profile adds items.
09:14:25 <benws> q?
09:14:33 <simonstey> ack simonstey
09:15:01 <michaelS> phil
09:15:37 <michaelS> phila: can a policy use more than 1 profile
09:15:44 <michaelS> benws: yes
09:16:02 <michaelS> phila: but what if the profiles are controversial
09:17:20 <michaelS> phila: cardinality is an area of potential conflicts
09:17:27 <simonstey> +q
09:17:36 <phila> ack s
09:18:31 <michaelS> simonstey: it is the responsibility of the party applying policies to check if they conflict
09:18:54 <michaelS> phila: all applied profiles are of equal standing
09:18:59 <michaelS> benws: yes
09:19:26 <benws> q?
09:19:35 <michaelS> phila: the ODRL validator must understand profiles and run validations against it
09:19:43 <michaelS> simonstey: this is not going to work
09:20:54 <michaelS> phila: a processor only understanding the core ODRL should be a fully valid one
09:21:19 <michaelS> ... a processor doesn't have to understand all (existing) profiles
09:21:41 <simonstey> +q
09:22:10 <renato> q+
09:22:32 <phila> ack s
09:23:21 <michaelS> simonstey: if we would live only in the RDF world SHACL could help - but not all users of ODRL will be living there
09:23:22 <phila> q+ to annoy Stuart
09:23:32 <phila> ack r
09:23:54 <michaelS> ... it would be good to have a standardized way to express additional constraints
09:24:01 <phila> ack me
09:24:01 <Zakim> phila, you wanted to annoy Stuart
09:24:52 <simonstey> +1
09:25:08 <michaelS> phila: should we require that an ODRL processor is able to work at the RDF level
09:26:57 <benws> q?
09:27:04 <michaelS> simonstey: acting at the RDF level would help - e.g. using SHACL to understand a Thomson Reuters profile
09:27:45 <michaelS> benws: ok, this could be done by ODRL 3
09:28:42 <renato> https://github.com/w3c/poe/issues/173
09:29:07 <renato> 10 min break
09:40:43 <simonstey> https://tools.ietf.org/html/rfc8174
09:40:52 <simonstey> Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words
09:41:34 <renato> back
09:42:28 <benws> We're back
09:43:20 <michaelS> benws: we have resolved POE issue #173
09:43:30 <michaelS> renato: yes
09:44:31 <renato> @simon you need to add an issue to: https://github.com/w3c/respec/issues
09:45:09 <michaelS> topic: normative vs non-normative in the specifications
09:45:32 <michaelS> benws: the normatie part should be as small as possible
09:47:17 <michaelS> benws: top level actions should include use and transfer - what else?
09:48:13 <michaelS> renato: all current actions are a narrower term of these two
09:48:44 <michaelS> benws: how does distribution fit into that?
09:48:54 <michaelS> renato: narrower term of use
09:49:08 <benws> q?
09:50:03 <phila> RESOLUTION: Use and Transfer are the only core Actions
09:50:13 <benws> +1
09:50:16 <michaelS> +1
09:50:16 <renato> +1
09:50:35 <simonstey> s/core/normative core/
09:50:49 <simonstey> +1
09:51:12 <michaelS> renato: any constraint leftOperands or operators in the core?
09:51:24 <michaelS> benws: no
09:51:59 <michaelS> renato:  duty actions?
09:52:10 <michaelS> benws: sees no need
09:53:06 <michaelS> renato: compount constraint operands?
09:53:49 <renato> s/compount/compound/
09:54:01 <michaelS> simonstey: example for "these operators MUST be supported" and more may be added
09:54:06 <michaelS> benws: supported that
09:54:53 <ivan> timing relationships?
09:55:58 <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.
09:56:02 <michaelS> benws: a processor should know if a policy is in effect
09:56:18 <michaelS> renato: showed the only rule regarding that
09:56:53 <simonstey> +q
09:57:12 <benws> ack s
09:57:19 <renato> https://w3c.github.io/poe/model/#provenace
10:00:13 <michaelS> simonstey: a time constraint could constrain the use of a policy
10:00:39 <michaelS> benws:   but the internal processing of constraints is not controled by ODRL
10:01:17 <michaelS> phila: we should use well understood properties to express if a policy is in effect
10:02:36 <renato> The Rule determines the validity period
10:02:59 <michaelS> ... 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
10:03:47 <simonstey> http://w3c.github.io/poe/vocab/#term-dateTime
10:04:19 <michaelS> benws: the ODRL core should not make any leftOperands mandatory - which is a conclusion from what was just said
10:05:22 <michaelS> ... clarified: the constaint on a policy should only be about date/times
10:06:27 <renato> https://w3c.github.io/poe/model/#provenace
10:11:15 <benws> q?
10:11:58 <renato> dc:time or odrl:time ;-)
10:12:22 <michaelS> 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 propertie are present.
10:12:47 <michaelS> s/propertie/properties/
10:13:18 <phila> RRSAgent, pointer?
10:13:18 <RRSAgent> See http://www.w3.org/2017/05/19-poe-irc#T10-13-18
10:13:25 <michaelS> ... any indiviual rule is only in effect if the policy is in effect
10:14:41 <benws> q?
10:14:46 <renato> @ben https://www.w3.org/2016/poe/track/actions/22
10:15:23 <michaelS> victor: should some leftOperands be normative?
10:16:12 <michaelS> benws: may be widely used but should not be normative
10:17:16 <ivan> q+
10:17:42 <michaelS> victor: what about the Vocabulary document
10:17:52 <michaelS> michaelS: ... will be slim
10:18:21 <simonstey> and the mapping to xml/json?
10:18:22 <michaelS> renato: but many terms will go into the non-normative vocabulary
10:19:47 <michaelS> benws: normative terms should go into the ODRL Info Model document, the current Vocabular should be change to a non-normative NOTE document
10:20:21 <simonstey> +q
10:20:24 <michaelS> victor: the ontology will be a non-normative document too?
10:20:39 <phila> q+ to say to make it a section, not an appendix
10:20:53 <phila> ack i
10:21:09 <michaelS> ivan: we jump ahead here - these are editorial issues
10:22:10 <michaelS> ... 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
10:23:00 <michaelS> ... why exactly should this vocab be not-normative.
10:23:36 <michaelS> ... re editorial part: ok, to move core actions etc into the Info Model - but is this easy to read?
10:24:03 <renato> isn't that editorial?
10:24:08 <michaelS> ... Users will have more look into something like the Vocab document but not the Info Model
10:24:21 <phila> q-
10:24:34 <michaelS> ... not sure that all is a good idea.
10:25:08 <phila> +1 to Ivan
10:25:13 <renato> About 30 terms
10:25:26 <michaelS> victor: concludes: also the ontology has to be split into non-/normative
10:26:24 <michaelS> simonstey: wondering what it means to have a normative ontology - but what impact on the serializations XML, JSON ...
10:26:33 <benws> q?
10:26:42 <benws> ack s
10:28:08 <michaelS> renato: we should have a normative Info Model and Vocabulary document and in addition a non-normative vocabulary document - as NOTE
10:28:11 <phila> q+
10:28:31 <Sabrina> Sabrina has joined #poe
10:28:35 <phila> ack me
10:29:46 <michaelS> phila: asked ivan if he is really against merging core vocabulary terms into the Info Model doc
10:29:48 <Sabrina> present+ sabrina
10:30:16 <benws> q?
10:30:19 <michaelS> ivan: yes, prefers to have a special Vocab document - even only with a few terms in it
10:30:43 <renato> https://www.w3.org/TR/annotation-vocab/#web-annotation-ontology
10:31:23 <victor> q+
10:31:52 <simonstey> https://github.com/w3c/poe/issues/104#issuecomment-277964079
10:31:59 <michaelS> renato:  shared a link to the Web Annotation Vocabulary - a kind of template?
10:32:40 <victor> q-
10:33:06 <renato> q+
10:35:16 <ivan> q+
10:36:09 <phila> ack r
10:36:24 <michaelS> victor: raised how to prove that an implementation complies with ODRL
10:36:47 <victor> +1 to renato proposal
10:36:50 <michaelS> Multiple replies: W3C trusts the providers of reports about success
10:37:50 <michaelS> renato: having a single vocuablary document with a mandatory and a non-mandatory parts
10:38:22 <michaelS> benws: would prefer to have explicit supports of profiles. At the time of the release of
10:38:30 <victor> -1 to having again a Creative Commons profile. I have seen no use of it in the past.
10:38:52 <michaelS> ... ODRL a RightsML and a financial services sector profile will be available
10:40:03 <michaelS> renato: would prefer to have an open/common profile which would make use of terms from the non-mandatory vocabulary.
10:40:16 <benws> q?
10:40:31 <phila> ack i
10:40:32 <michaelS> ... it would be good to see if some vocab terms are adopted widely
10:41:18 <michaelS> ivan: leans towards renato's view
10:41:39 <renato> "common" vocab
10:42:51 <renato> "An ODRL Profile will directly serve the communities needs"
10:43:09 <michaelS> Discussion about the scope of profiles: for a wider audience or only for narrower special audiences
10:44:13 <michaelS> q+
10:44:30 <ivan> q-
10:44:56 <phila> RRSAgent, make logs public
10:45:01 <michaelS> renato: proposed to call the non-mandatory terms as "ODRL common vocabulary"
10:45:12 <phila> ack m
10:46:04 <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
10:46:13 <phila> michaelS: Common vocab or common profile?
10:46:16 <phila> benws: Common profile
10:46:38 <phila> michaelS: You proposed, renato, to call this a common vocabulary
10:47:01 <phila> renato: True. It's not trying to meet a particular community
10:47:16 <phila> ... So other people are encouraged to use these as they wish in *their* profiles
10:47:35 <phila> ... It's not really our goal to provide the business requirements for a specific sector
10:48:08 <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
10:48:29 <michaelS> phila: undestands what benws wants to say
10:48:42 <michaelS> ... but a common profile is not for a specific community
10:49:09 <michaelS> benws: this common profile should only show what can be done with profile
10:49:20 <michaelS> phila: who would use that common profile?
10:49:36 <michaelS> benws: people having first looks at ODRL
10:50:42 <michaelS> phila: if IPTC and W3C create a joint RightsML profile - what is its relationship to the common profile
10:51:39 <michaelS> renato: profiles should aim at people having a specific interest
10:51:52 <benws> q?
10:51:54 <michaelS> phila: proposes to name it Generic Profile
10:53:01 <phila> PROPOSED: That the terms in the vocabulary, not in the normative core, be published as a generic profile
10:53:02 <renato> Split the current single Vocabulary section into two:
10:53:02 <renato> "4. ODRL Core Vocabulary" (normative)
10:53:02 <renato> "5. ODRL Generic Profile" (non-normative)
10:53:16 <simonstey> we then have to add odrl:profile statements to all examples in the IM that use actions != use/transfer
10:53:18 <phila> PROPOSED: That the terms in the vocabulary, not in the normative core, be published as the Generic Profile
10:53:46 <simonstey> +q
10:53:59 <phila> acsk s
10:54:01 <phila> ack s
10:54:41 <phila> simonstey: We're talking about additional actions. When does the new profile start. Is Alice's Party a new profile now?
10:54:59 <phila> ... I need a profile to add new parties etc.
10:55:12 <phila> ... As R said what actually constitutes a profile?
10:55:20 <phila> ... We add new semantics, yes...
10:55:29 <phila> ... but how do you integrate the profile in your model.
10:55:39 <phila> simonstey: What does it mean that the profile is adding semantics?
10:55:57 <phila> benws: If we can it a core vocab or a core profile, does the issue go away?
10:56:20 <renato> q+
10:56:23 <phila> benws: If we say, it's part of the core model, does the problem disappear?
10:56:29 <victor> simon:query
10:56:34 <phila> simonstey: I define a new action simon:query
10:56:46 <phila> ... I have to somehow magically integrate that into the core.
10:56:47 <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""
10:57:08 <phila> simonstey: Currently I don't have to define my profile I can just use it in a policy
10:57:17 <phila> benws: And why does this change with profiles?
10:57:29 <phila> simonstey: My question is: what does a profile need to contain?
10:57:39 <michaelS> q+
10:57:44 <phila> renato: This is what I asked - what is the purpose of the profile property?
10:57:51 <phila> scribeNick: phila
10:57:54 <ivan> q+
10:57:59 <victor> (in fact current examples use terms from external vocabularies, like vcard)
10:58:22 <ivan> q-
10:58:22 <phila> renato: If I use the generic profile, so I now need to understand all the terms in the common profile?
10:58:30 <phila> ... That'[s why I think it's a common vocabulary
10:58:45 <victor> I prefer common vocabulary over profile as well.
10:58:45 <phila> benws: So can I create a common vocab for exchange data rather than a profile for it
10:58:55 <phila> ... And what's the difference between creating a profile and a vocab?
10:59:29 <phila> michaelS: I see the difference - if you create a processor that processes a profile, then all the features in the profile must be supported
10:59:35 <ivan> q+
10:59:40 <renato> q-
10:59:51 <phila> ... If we make the 25-30 actions in the generica profile, then a generic profile processor must understand them all.
11:01:13 <phila> 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]
11:01:19 <simonstey> odrl:acceptProfile "simon"
11:01:30 <phila> benws: We can't guarantee that the processor will understand all the terms.
11:01:33 <simonstey> -> understand all terms with prefix simon:
11:01:43 <phila> q+ to talk about the generic profile being too big
11:01:47 <phila> ack m
11:02:22 <ivan> q-
11:02:26 <phila> michaelS: I consider the common vocab not as a profile but a grab bag of terms that can be used
11:02:27 <renato> q+
11:02:32 <phila> ack me
11:02:32 <Zakim> phila, you wanted to talk about the generic profile being too big
11:03:39 <ivan> +1 to Phil
11:04:46 <phila> phila: Suggests that we create a profile from a subset of the common vocab
11:05:37 <phila> 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
11:06:03 <phila> benws: But does that mean that we#'re mandating the use of at least one profile?
11:06:10 <victor> +1 to Phil too...
11:06:19 <phila> michaelS: Only if they want to go beyond the core
11:06:32 <phila> benws: The core doesn't allow you to use ODRL in the real world
11:06:38 <victor> perhaps we want to hear Stuart's opinion in the next call
11:07:47 <phila> 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
11:07:51 <benws> q?
11:07:55 <phila> ... No problem
11:08:21 <phila> renato: I want to support... if we document how you would use the common vocab, then we need to do that and prove it.
11:08:36 <phila> ... But the purpose is that you create a profile that might use some of the common terms
11:08:55 <phila> michaelS: I think it even more supports the requirement to use a profile.
11:09:08 <phila> ivan: To do anything for a spedcific industry there must be a profile
11:09:17 <phila> michaelS: And it would be good to have some examples
11:09:21 <michaelS> q+
11:09:29 <phila> ack r
11:09:30 <renato> q-
11:09:37 <phila> ack m
11:10:00 <phila> michaelS: We could invite the use case providers to create profile for their use case.
11:10:18 <phila> victor: I can provide the small policy on data. Where we need 7 or 8 terms.
11:10:21 <renato> Split the current single Vocabulary section into two:
11:10:21 <phila> benws: Great.
11:10:21 <renato> "4. ODRL Core Vocabulary" (normative)
11:10:21 <renato> "5. ODRL Common Vocabulary" (non-normative)
11:10:23 <renato> (later used as a possible source for Profiles)
11:10:42 <phila> victor: There will be profiles that are not official
11:10:46 <phila> phila: (they don't need to be)
11:10:49 <renato> s/later/latter/
11:10:58 <victor> This is how we used ODRL to license linked data
11:10:59 <victor> http://purl.oclc.org/NET/ldr/ns#
11:11:25 <phila> victor: Talks through the doc ^^
11:12:58 <benws> q?
11:14:18 <phila> 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.
11:14:25 <renato> BRB..
11:14:29 <phila> ... And that's your CR Exit Criteria met
11:14:54 <renato> back
11:15:55 <victor> you can the see the software running as a linked data server, see here: http://conditional.linkeddata.es/ldr/resource/Provincia/Valencia
11:16:12 <victor> (only for the record, not now obviously)
11:16:55 <phila> phila: DRAFTs
11:16:55 <phila> PROPOSED: That we will publish the non normative vocab terms as the 'ODRL Common Vocabulary' but *not* as a Profile.
11:16:55 <phila> 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
11:18:20 <victor> ping
11:18:36 <phila> PROPOSED: That the vocabulary terms that form the Core Model will be published as normative elements in that Recommendation
11:19:22 <phila> PROPOSED: That the vocabulary terms that form the Core Model will be published as normative elements in that Recommendation
11:19:55 <phila> [Consensus to vote on all three]
11:19:56 <simonstey> in that rec. refers to what?
11:19:57 <ivan> +1 +1 +1 +1
11:19:58 <renato> +3
11:20:03 <michaelS> +1 +1 +1
11:20:15 <phila> +3
11:20:24 <Sabrina> +1 +1 +1
11:20:34 <simonstey> +3
11:21:01 <renato> rec = "Vocab" document
11:21:13 <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)
11:21:30 <phila> RESOLUTION: That the vocabulary terms that form the Core Model will be published as normative elements in that Recommendation
11:21:30 <phila> RESOLUTION: That we will publish the non normative vocab terms as the 'ODRL Common Vocabulary' but *not* as a Profile.
11:21:30 <phila> RESOLUTION: 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
11:22:21 <renato> Late dinner ;-)
11:22:57 <victor> (this diagram will be anyway needed to illustrate these complex ideas to the ODRL readers)
11:23:06 <renato> Back at 1:15 London time
11:24:04 <michaelS> = 14:15 IRC time
11:55:02 <benws> benws has joined #poe
12:05:28 <michaelS> kk
12:05:54 <phila> phila has joined #poe
12:14:20 <renato> This is Brisbane...12 Points to....
12:16:04 <renato> q+ are the serialisations normative?
12:17:11 <renato> q+ to ask are the serialisations normative
12:18:39 <phila> [Resume after the break]
12:18:42 <simonstey> ack renato
12:18:42 <Zakim> renato, you wanted to ask are the serialisations normative
12:18:56 <ivan> q+
12:19:40 <phila> ack i
12:19:49 <renato> https://w3c.github.io/poe/vocab/#encodings
12:19:54 <victor> (http://w3c.github.io/poe/vocab/#encodings
12:20:03 <simonstey> and xml?
12:20:05 <Sabrina> Sabrina has joined #poe
12:20:11 <phila> ivan: The normative, is the RDF vocab, then there are standards to serialise it in (say, Turtle, triples etc.)
12:20:26 <phila> ... But the RDF serialisations as JSON-LD etc. are not normative
12:21:00 <phila> 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
12:21:25 <phila> ... In 5.3 is also meaningless - we should just say that we provide the context file.
12:21:33 <phila> ivan: I don't know about the XML encoding
12:21:39 <phila> michaelS: What about the JSON encoding?
12:21:46 <phila> ivan: That's not in this doc for now
12:22:07 <phila> ... I think we said that there's no need to have a separate JSON encoding as we have JSON-LD
12:22:30 <phila> renato: So... we can't just say section 5 is informative?
12:22:39 <simonstey> https://github.com/w3c/poe/issues/46
12:22:45 <phila> ivan: It depends on the XML
12:22:57 <phila> renato: I assume that the XML encoding is informative too
12:23:06 <phila> ivan: That's not what it necessarily means
12:23:22 <phila> ... We may have to have some proven exchanges
12:23:51 <phila> ... So you'd have something to ingest XML and process with same semantics as RDF
12:24:10 <phila> ... If there's only one implementation of the XML then there's no need to make it normative.
12:24:26 <phila> simonstey: We have terms that are only there to support the XML serialisation
12:24:46 <phila> ... It's not just about normative/not normative
12:25:00 <phila> RRSAgent, draft minutes v2
12:25:00 <RRSAgent> I have made the request to generate http://www.w3.org/2017/05/19-poe-minutes.html phila
12:25:12 <phila> renato: I think we have to mark section 5 as informative. Anyone disagree?
12:25:49 <phila> 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.
12:26:10 <phila> renato: We should validate the XML
12:26:22 <phila> ... It has been kept up to date with the schema
12:26:27 <phila> ... I'm doing it as we go through
12:26:52 <phila> 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
12:27:00 <victor> I find this asymmetry somewhat strange
12:27:23 <phila> 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.
12:27:39 <phila> renato: So where would you put the note about the context file?
12:27:54 <phila> ivan: Do you not have a section with namespaces, conformance etc?
12:28:18 <phila> ivan: Is the ODRL namespace the only one we ever use or are there references to others
12:28:23 <phila> michaelS: Dublin Core
12:28:28 <phila> renato: OWL, SKOS etc.
12:28:45 <phila> ivan: There's a habit to list the namespaces used in the doc.
12:29:06 <phila> ... And in that namespace, you add the info that the ODRL ontology is at X, context file is at Y etc.
12:30:52 <phila> phila: I'd just put the context file at the same place as the ontology and use conneg
12:30:58 <phila> ivan: No, they're different things
12:31:52 <phila> ivan: We need to make sure that all the changes in the doc are listed in the change log.
12:32:02 <phila> ... Should be a change log since the latest publication
12:32:10 <phila> ... The current version has been through horizontal reviews
12:32:40 <phila> ... I have been bitten by later reviews in CR etc. when changes in docs were not properly described.
12:32:48 <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 ]
12:33:10 <phila> renato: I can work out from that bullet point list now hat goes where.
12:33:16 <renato> q?
12:33:20 <phila> s/now hat/now what/
12:33:40 <phila> renato: We had a few things on the agenda...
12:34:10 <phila> ... we wanted to look at the 2 notes, the Exit Criteria, and the test suite
12:34:21 <phila> ... Let's assume we've been through all the issues and made the changes
12:34:56 <phila> ...  We then to identify the exit criteria and the test suite lined up.
12:35:18 <phila> ... Working through the 2 docs, I can see how they go, but what about the CR exit criteria?
12:35:25 <ivan> q+
12:35:35 <phila> ack i
12:35:46 <phila> ivan: It's a little more than that.
12:36:09 <phila> ... 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.
12:36:43 <phila> ... It has to be clear, usually, for APIs, they have to be 2 independent implementations that produce the same output.
12:37:09 <phila> ... 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.
12:37:41 <phila> ... Do we want to have at least 2 independent implementations/usage of the core technologies
12:37:51 <phila> ... Showing that they're useful and ready to deploy.
12:38:05 <phila> ... That shows that what we did was meaningful
12:38:53 <phila> ... 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.
12:39:12 <phila> renato: So with the work with OA, which looks related, what can we learn?
12:39:21 <phila> ivan: (looks for exit criteria statement)
12:39:53 <ivan> https://www.w3.org/TR/annotation-model/#candidate-recommendation-exit-criteria
12:40:30 <phila> ivan: I'm not sure that it translates exactly into this space
12:40:43 <phila> renato: That's a set of features that look like the mandatory parts of the IM
12:41:04 <phila> ... A policy with a constraint, an agreement etc.
12:42:54 <phila> phila: The core is normative, most of the common vocab is not
12:42:58 <ivan> https://www.w3.org/TR/annotation-vocab/#candidate-recommendation-exit-criteria
12:43:08 <phila> ivan: For the OA vocab, we concentrated on...
12:43:37 <phila> ... We have an abstract model that we translate into RDF, are we sure that the RDF ontology is consistent with the model.
12:43:43 <phila> ... That needs testing
12:43:57 <phila> ... That's where we focussed for Open Annotations
12:44:43 <phila> ... 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.
12:46:45 <ivan> Examples for implementation reports https://w3c.github.io/test-results/annotation-model/all.html
12:46:52 <ivan> http://w3c.github.io/test-results/annotation-vocab/all.html
12:46:56 <phila> phila: Explains limited number of days to work on this after which I may or may not be on the team
12:48:07 <phila> [Discuss OA test suite created by Shane McCarron]
12:48:13 <phila> ivan: This is a lot of work.
12:48:31 <phila> ... Given Phil's situation, I think someone else should take charge
12:48:34 <phila> renato: I agree
12:48:57 <phila> ... We need dedicated effort and leadership on this task otherwise the 2 specs will fall.
12:49:24 <phila> ... So can someone volunteer to take this on?
12:49:30 <phila> phila: Looks at simonstey ;-)
12:50:25 <phila> 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
12:50:34 <phila> q+
12:50:45 <phila> simonstey: I'd tackle the thing from a tech perrspective
12:50:55 <phila> ... We're open in how we define our test cases.
12:51:15 <victor> I agree with Simon, this is something difficult to assess.
12:51:17 <phila> ... There's this aspect of checking whether a policy produced conforms to our requirementes
12:51:21 <phila> ack me
12:51:46 <ivan> q+
12:51:48 <renato> phila: test the validator and evaluator
12:51:56 <phila> ack i
12:52:10 <phila> ivan: I understand what simonstey says - we have to have an understanding of the whole CR is made for,
12:52:26 <phila> ... Its primary purpose is to prove that the spec is consistent, implementable and useful.
12:52:46 <phila> ... There may be instances of ODRL that express rubbish, but we can't check, nor do we have to.
12:52:52 <simonstey> https://github.com/simonstey/ODRL-SHACL-Shapes/wiki/SHACL-Shapes-for-validating-ODRL-Policies
12:52:54 <phila> ... We have to draw a line somewhere.
12:53:32 <phila> simonstey: I don't know how I'd tackle the XML side - nor do I have any inclination to test it.
12:53:53 <phila> ivan: If we are careful to make the XML non-normative, we don't have to test it. CR only tackles normative features.
12:54:10 <phila> ... So for testing, we can forget about XML
12:54:19 <phila> q+ to ask about XML
12:54:51 <phila> simonstey: I'm also busy of course and I have to finish my PhD at some point. SO someone else would be helpful too.
12:54:58 <phila> ack me
12:54:58 <Zakim> phila, you wanted to ask about XML
12:55:41 <benws> benws has joined #poe
12:56:19 <phila> phila: If XML is informative, can an XML-based implementation be adduced as evidence of ODRL implementation?
12:56:32 <phila> [crickets]
12:56:56 <phila> ivan: Our model is in RDF, and our serialisations in RDF have a bunch of standards already.
12:57:31 <phila> 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.
12:58:14 <phila> ivan: The implementation that we use for testing should be able to read in one of our RDF serialisations
12:59:09 <phila> renato: What tech will TR use?
12:59:16 <phila> benws: RDF
12:59:24 <phila> renato: Caroline says theirs is in JSON
12:59:54 <phila> victor: What we have is ODRL 2.1 so we need to update
13:00:05 <phila> ... I can commit to updating docs but not software.
13:00:10 <michaelS> q+
13:00:17 <ivan> q+
13:00:18 <phila> renato: That's why it's important to work on the test cases
13:00:27 <phila> q/
13:00:29 <phila> q?
13:00:34 <phila> ack m
13:00:57 <phila> michaelS: I'd like to suggest that today we list what needs to be done
13:01:12 <phila> ... And then discuss on the next call
13:01:38 <phila> michaelS: We have to make some checks with WG members not present right now
13:01:39 <ivan> q-
13:01:56 <phila> victor: And having more  test cases is important too.
13:02:04 <simonstey> https://github.com/simonstey/ODRL-SHACL-Shapes/wiki/SHACL-Shapes-for-validating-ODRL-Policies
13:03:32 <phila> benws: Once the test cases exist, then people can assess how much work is involved in implementing
13:03:46 <phila> benws: So what's left on the agenda?
13:04:04 <phila> ... I'd like to hear about the formal semantics and best practices
13:04:07 <phila> renato: Yep.
13:04:13 <michaelS> q?
13:04:38 <phila> renato: Simon has volunteered to work with Phil to get the test cases going and then if Phil goes we'll need someone else.
13:05:11 <phila> renato: We have some examples of how to do tests
13:05:24 <victor> https://www.w3.org/2016/poe/wiki/Best_Practices
13:05:27 <phila> Topic: Best Practices
13:05:39 <phila> RRSAgent, draft minutes v2
13:05:39 <RRSAgent> I have made the request to generate http://www.w3.org/2017/05/19-poe-minutes.html phila
13:05:52 <phila> victor: You'll see 16 examples from the spec. I need someone to look and review
13:06:11 <phila> ... And is this the right format/structure
13:06:15 <ivan> q+
13:06:41 <simonstey> https://www.w3.org/TR/dwbp/ ? ;)
13:07:02 <phila> phila: Recent BP docs aren't relevant here (such as DWBP)
13:07:21 <phila> ivan: Jeni did a great job for CSV on the Web, but again, it's not the same kind of doc.
13:07:54 <phila> benws: How to make an offer (eg 7) - It needs a paragraph to introduce it.
13:08:08 <phila> ... Policy Type etc. I'm happy to write those paragraphs.
13:08:18 <phila> ivan: All the examples are in JSON-LD
13:08:26 <simonstey> me2
13:08:30 <phila> ... I am probably like Victor, I prefer Turtle
13:08:34 <phila> q+
13:09:10 <phila> -> https://www.w3.org/TR/vocab-duv/ Dataset Usage Vocabulary
13:09:13 <phila> q-
13:10:09 <ivan> +1 to ben
13:10:26 <phila> 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.
13:10:38 <phila> victor: Who is the reader of this doc?
13:10:59 <phila> benws: I think it's someone who has business problems and wants to see whether ODRL can solve them.
13:12:03 <phila> victor: Will there be a section in the UCR showing where each req is met?
13:12:16 <phila> phila: Normally the other way round. The Rec shows here the Reqs were met
13:12:51 <phila> ivan: Maybe take one or two examples from the BP doc, pref with real world data, show how the data is validated and evaluated.
13:13:04 <phila> ivan: Not for all of them - it's too much - but take a couple of examples.
13:13:12 <phila> ... They could come from the UCR
13:13:22 <phila> victor: That's a lot of work
13:13:37 <phila> renato: Remember the use cases we got from BSIG/Bill K
13:13:44 <phila> ... Can we look at some of those?
13:13:58 <phila> benws: Good idea.
13:14:27 <phila> renato: So, Victor, this you get this list by going through the IM?
13:14:29 <phila> victor: Yes.
13:15:03 <phila> 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
13:15:08 <phila> victor: Is this for developers?
13:15:21 <phila> benws: No, it's I have business problems, does ODRL solve them? If so, how?
13:16:06 <phila> renato: And I assume this will be translated to a ReSpec doc on GH?
13:16:46 <renato> http://w3c.github.io/poe/bp/
13:16:50 <phila> benws: Will GH allow us to do the Turtle/JSON-LD Switch?
13:16:57 <phila> phila: It's a JS library
13:17:06 <phila> renato: Did Paul Jessop get back to you?
13:17:15 <phila> benws: No.
13:18:08 <phila> Topic: Formal Semantics
13:18:09 <simonstey> https://www.w3.org/2017/04/11-poe-minutes.html
13:18:40 <phila> simonstey: That's the one meeting we had ^^
13:18:57 <phila> .. It w as primarily that we need to clarify what the FS doc should cover.
13:19:33 <phila> ... We left it out today. It only makes sense if there's something like conflict management. You need something more precise than natural language.
13:19:57 <phila> ... We didn't talk about whether an evaluator should merge policies
13:20:07 <phila> ... The black box Constraint Checker helps
13:20:20 <phila> ... we'll need further discussions of course.
13:20:37 <simonstey>  http://link.springer.com/chapter/10.1007%2F978-3-319-21542-6_23
13:20:38 <phila> .. The scope of the FS document... Ivan looked at my paper. Very helpful
13:21:02 <phila> ... He also said that there is a fine line between being too abstract and being too informal
13:21:17 <phila> simonstey: Taking this paper as the basis, might be too much
13:21:22 <phila> q+ to ask about collections
13:21:35 <ivan> q-
13:21:39 <phila> simonstey: I think we should be clear what we expect from the FS document
13:22:03 <renato> q+
13:22:05 <phila> ... For the validation part, then the SHACL files don't need guidance, but for evaluation, you do.
13:23:02 <phila> benws: There are 3 use cases I'd find useful
13:23:39 <phila> 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.
13:23:45 <renato> q-
13:24:13 <phila> ... 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.
13:24:18 <Sabrina> interesting usecase Ben.....
13:24:40 <phila> simonstey: This is interesting
13:24:45 <phila> ... That's not covered by the IM
13:24:56 <phila> ... There's nothing about policy merging in there
13:25:06 <phila> ... We have policy conflicts
13:25:23 <phila> ... The approach would be you take all the rules from one policy and put it in another.
13:26:11 <phila> 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
13:26:44 <phila> ... Without that, it boils down to a specific action - is it allowed or not?
13:26:58 <phila> benws: But the common vocab will give us that hierarchy of actions
13:27:23 <phila> simonstey: I think this is super important for the IM (Antoine Isassc raised it)
13:27:35 <phila> s/Isassc/Isaac/
13:27:55 <phila> benws: How should you represent them?
13:28:12 <phila> Sabrina: You have an arc saying broader or narrower
13:28:23 <phila> benws: Do we use SKOS to do that? SubTyping?
13:28:33 <phila> simonstey: We have neither currently
13:29:20 <phila> simonstey: What effect might this have on XML?
13:29:25 <phila> benws: Can we punt that?
13:29:34 <phila> renato: It's not an issue, XML can just use a URI
13:29:44 <phila> ... But we have decided that it's informative...
13:29:56 <renato> 	skos:broaderTransitive odrl:use ;
13:30:00 <phila> ... It's not in our remit to explain how to use XML
13:30:21 <phila> benws: Do we want to support hierarchies of actions?
13:30:23 <Sabrina> +1 hierarchies in general
13:30:37 <phila> simonstey: Yes, on actions, but we can do more
13:30:53 <phila> simonstey: Primarily it's about relating actions to each other.
13:31:33 <phila> ... 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
13:32:20 <phila> PROPOSED: That hierarchies be expressible between actions
13:32:36 <phila> victor: I have witnessed endless discussions about this and people may not agree.
13:32:42 <phila> benws: They'll be defined in profiles
13:32:47 <Sabrina> We should not define the hierarchy.....
13:32:55 <phila> simonstey: Yes. We say how to do it.
13:33:25 <ivan> q+
13:33:34 <simonstey> +1
13:33:34 <Sabrina> We just need the ability to generate hierarchies
13:33:45 <phila> simonstey: If the hierarchy is defined then a conflict may be detected. If no hierarchy, then there's no conflict
13:33:46 <phila> q-
13:33:58 <phila> benws: I know I'll spend a lot of time discussing this here
13:34:26 <ivan> +1
13:34:29 <phila> ivan: Just for my understanding - in the model, we give some means to express this hierarchy, which is then normative and therefore testable.
13:35:24 <phila> victor: You can imagine that selling is a type of distribution... [sorry lost this]
13:35:31 <phila> PROPOSED: That hierarchies be expressible between actions
13:35:37 <ivan> +1
13:35:38 <renato> +1
13:35:39 <benws> +1
13:35:39 <simonstey> +1
13:35:43 <Sabrina> +2
13:35:54 <Sabrina> lol
13:35:59 <victor> two relations: "selling is a type of distributing" and "editing" implies "rendering".
13:36:01 <michaelS> +1
13:36:04 <phila> RESOLUTION: That hierarchies be expressible between actions
13:36:05 <victor> +1
13:36:32 <phila> ivan: So how do we express this...
13:36:44 <phila> benws: Are we talking about one or two hierarchies?
13:36:52 <renato> skos:narrower?
13:37:06 <phila> victor: One is inheritance, and the other is relationships
13:37:35 <Sabrina> one is inheritance and another is a dependency
13:37:44 <phila> simonstey: We don't have to define those, we just have to facilitate it. Editing implies rendering etc.
13:37:55 <victor> simply declaring a new property called hasNecessaryAction
13:38:13 <victor> requiredAction
13:39:07 <phila> 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)
13:39:12 <simonstey> +q
13:39:17 <Sabrina> we should have to look at the semantics of the other vocab
13:39:42 <ivan> q-
13:39:45 <phila> 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
13:40:11 <phila> simonstey: If we introduce our own properties, then we have the formal semantics to define what those semantics are.
13:40:17 <phila> ack s
13:40:52 <phila> simonstey: If you rely on sub* then we would be fine saying just look it up.
13:41:11 <phila> ivan: But the question is whether the formal semantics of RDF impose things we don't want?
13:41:19 <phila> simonstey: Not if we had our own property
13:41:36 <phila> ivan: Indeed. But if we rely on rdfs:subProperty
13:41:41 <phila> ivan: I'm not sure we want that
13:41:46 <phila> simonstey: I agree
13:42:21 <simonstey> https://aic.ai.wu.ac.at/~polleres/publications/stey-poll-2015RuleML.pdf
13:42:30 <simonstey> section 3.1
13:43:49 <Sabrina> Shouldn't this be usecase driven?
13:44:50 <phila> PROPOSAL: We support two hierarchies: requires and inheritance
13:45:38 <phila> PROPOSAL: We support hierarchy with two properties - requires and inheritance
13:46:01 <phila> PROPOSAL: We support hierarchy with two properties - requires and narrows
13:46:04 <simonstey> +1
13:46:07 <phila> q+
13:46:34 <phila> q-
13:46:40 <ivan> +1
13:46:46 <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)
13:47:04 <michaelS> +1 requires, -1 narrows
13:48:15 <phila> [Further discussion around sharing as example of requiring permission to distribute]
13:48:41 <phila> renato: So one permission leads to two permissible actions
13:49:59 <phila> 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.
13:50:22 <phila> ivan: Doesn't 'requires' cover that?
13:50:37 <phila> simonstey: [mumble] yeah
13:50:46 <phila> ivan: So why do we need 2
13:51:07 <victor> q+
13:51:20 <phila> ivan: If we have an expression to relate 2 actions in one direction, why have 2?
13:51:26 <phila> simonstey: I started from the ODLR ontology
13:52:24 <phila> 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
13:52:37 <phila> ivan: I can express that with requires
13:53:06 <phila> michaelS: This is tricky. If you want to print, what does 'requires present' mean?
13:53:24 <phila> ivan: If there is no other rule, OK. But if there is, there may be a conflict and this detects it.
13:54:00 <phila> michaelS: Hearing the proposal about requires...
13:54:15 <phila> renato: So you can go across the hieracrhy, not necessarily up
13:54:42 <phila> 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.
13:55:02 <phila> benws: In that discussion... did you agree that we only need one hierarchy?
13:55:09 <phila> ivan: I think 1 is enough
13:55:10 <Sabrina> q+
13:55:16 <phila> simonstey: I agree, 1 is enough
13:55:31 <phila> benws: It's the nature of that relationship that we're discussing
13:55:55 <phila> benws: Do you agree that we need one relationship?
13:56:11 <simonstey> transitive closure
13:56:21 <phila> michaelS: Yes... if you have this hierarchy, a broader action permitted, then you may also take a narrower action.
13:56:30 <phila> benws: Are the three of you now in agreement.
13:56:51 <phila> simonstey: There may be share and distribute but they're not in a hierarchy
13:57:04 <phila> michaelS: SO this goes across the hierarchy
13:57:22 <phila> ... If you have a broader action permitted then you may take the narrower one.
13:57:34 <phila> benws: And is it the only relationship wew need
13:57:40 <phila> ivan: For the use cases I have heard,, yes.
13:57:44 <phila> ack v
13:58:16 <phila> 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.
13:58:31 <phila> benws: It sounds as if we just need one single relationship
13:58:33 <phila> ack s
13:58:34 <renato> +1 to single relationship "narrow"
13:58:49 <phila> Sabrina: I see the need for requires
13:59:31 <phila> ... 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
14:00:00 <phila> benws: Is the broader/narrower needed for the FS or is it requires
14:00:11 <phila> simonstey: You need both
14:00:43 <phila> [Repeat discussion]
14:01:10 <phila> benws: I thought Ivan was saying e only need one
14:01:22 <phila> Sabrina: He was asking a question, not making a statement.
14:01:38 <phila> q+
14:01:53 <michaelS> q+
14:02:15 <phila> ivan: We started with a formal semantics discussion - there may be conflicts and these have to be handled somehow.
14:02:16 <phila> q-
14:02:33 <phila> ivan: What you describe, Sabrina, is not the same
14:02:39 <phila> ... Wwe're mixing 2 differnet things.
14:02:58 <simonstey> +1 to what ivan said
14:03:07 <phila> ... The narrower relationship is a convenience one, but requires is different and we shouldn't mix them.
14:03:14 <phila> michaelS: I try to figure out 3 cases
14:03:54 <simonstey> http://w3c.github.io/poe/model/#conflict
14:03:54 <phila> ... 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.
14:04:03 <victor> q+
14:04:04 <simonstey> prohibit: the Prohibitions MUST override the Permissions
14:04:13 <simonstey> perm: the Permissions MUST override the Prohibitions
14:04:15 <phila> ... The broader term is permitted and so are the narrower ones, unless prohibited.
14:04:43 <phila> michaelS: Other way round... you have permission to print but prohibition to present. Present wins and you can't print.
14:05:14 <simonstey> in the profile
14:05:25 <simonstey> no
14:05:30 <phila> ... 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?
14:05:45 <simonstey> no
14:05:48 <simonstey> not prohibited
14:05:53 <phila> simonstey: The requires - what does that mean - that the required action is explicitly permitted?
14:06:04 <phila> s/simonstey/michael/
14:06:24 <phila> [Scribe error, previous statements by Michael, not Simon]
14:06:44 <phila> simonstey: Summarises
14:07:22 <phila> ... Can say invalid if any conflict, then the permission to share and the distribute all invalid.
14:07:32 <phila> michaelS: Shouldn't we say "must not be prohibited"
14:07:39 <phila> simonstey: That's along property name
14:07:47 <phila> michaelS: But the semantics are better
14:08:00 <phila> simonstey: There are no semantics in a term name
14:08:02 <renato> q+
14:08:10 <phila> ... I'm not in favour of a term nae 40 characters long
14:08:15 <benws> ack michael
14:08:17 <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)
14:08:18 <trackbot> Error finding 'herarchies'. You can review and register nicknames at <https://www.w3.org/2016/poe/track/users>.
14:08:19 <phila> s/nae/name/
14:08:30 <phila> victor: Let me remind you about ^^ figure 2
14:08:43 <phila> victor: Very old
14:09:01 <renato> What a great looking figure ;-)
14:09:05 <phila> victor: Do we need to discuss more of relevance today?
14:09:21 <phila> benws: It would be good to make progress so that Simon can begin work
14:09:55 <phila> victor: The actions that generate a new asset are worth looking at, as is next Policy
14:10:13 <renato> q?
14:10:17 <phila> ack v
14:10:20 <phila> ack r
14:10:46 <phila> renato: I'd like to understand... narrower I understand... but what's the actual use case for requires?
14:11:13 <phila> simonstey: In the paper, again, share/distribute - there must be a conflict
14:11:37 <phila> renato: But isn't that a poorly defined action?
14:11:41 <phila> q+
14:12:20 <phila> simonstey: You can define your default policy behaviour... maybe that it applies to everyone and then specific ones that allow you make exceptions
14:13:00 <phila> renato: We had a similar discussion around distribute. That also includes the ability to copy.
14:13:17 <Sabrina> yes....
14:13:46 <phila> renato: My response is - if you need both - if distribute can include copy...
14:13:52 <phila> benws: It's getting too complicated
14:14:09 <phila> ack me
14:15:09 <Sabrina> in my mind distribute and copy are autonomous  - but some may argue both have the root of use
14:15:26 <renato> :-)
14:15:27 <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]
14:15:44 <victor> ermission to copy, because you can't distribute without copying.
14:15:51 <phila> benws: It sounds as we need both to support the use cases
14:15:57 <simonstey> both are transitive
14:16:15 <Sabrina> lol
14:16:32 <phila> PROPOSED: That we introduce 2 properties that (whatever their names) mean transitive 'narrower' and 'non-transitive requires'
14:16:35 <renato> yes you can....I gave you 1000 copies to distribute
14:16:58 <phila> PROPOSED: That we introduce 2 properties that (whatever their names) mean transitive 'narrower' and 'requires'
14:17:02 <phila> PROPOSED: That we introduce 2 properties that (whatever their names) mean transitiv 'narrower' and 'requires'
14:17:03 <simonstey> +1
14:17:08 <phila> PROPOSED: That we introduce 2 properties that (whatever their names) mean 'narrower' and 'requires'
14:17:13 <simonstey> +1
14:17:18 <benws> +1
14:17:20 <phila> +1
14:17:20 <Sabrina> +1
14:17:27 <ivan> +1
14:17:27 <renato> +0.49
14:18:05 <Sabrina> silence is taken as agreement
14:18:09 <Sabrina> :)
14:18:13 <victor> +0.5
14:18:15 <michaelS> narrower +1, "requires" -1
14:19:05 <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!)
14:19:31 <renato> Yup :-)
14:19:51 <renato> Atomic actions are better option
14:20:00 <phila> PROPOSED: That we introduce 2 properties that (whatever their names) mean a hierarchical relationship and a non-hierarchical relationship between actions
14:20:23 <phila> victor: Expresses concern...
14:20:27 <phila> benws: Satisfies
14:20:43 <phila> PROPOSED: That we introduce 2 properties that (whatever their names) mean a hierarchical relationship and a non-hierarchical relationship between actions
14:21:16 <phila> renato: I'm happy with consensus with my vote
14:21:25 <phila> RESOLUTION: That we introduce 2 properties that (whatever their names) mean a hierarchical relationship and a non-hierarchical relationship between actions
14:21:30 <michaelS> +1
14:21:35 <phila> RRSAgent, draft minutes
14:21:35 <RRSAgent> I have made the request to generate http://www.w3.org/2017/05/19-poe-minutes.html phila
14:21:37 <benws> +1
14:21:53 <phila> ivan: How to we express that - an extra triple between two actions? Where does it appear?
14:22:15 <simonstey> odrl:present odrl:narrower odrl:use .
14:22:26 <victor> exactly.
14:22:49 <phila> ivan: So this is something that a profile could include
14:23:26 <victor> in the ontology we have skos:broaderTransitive
14:23:28 <victor> already!!
14:23:29 <phila> victor: We already have SKOS narrower etc. in the actions ontology
14:23:44 <phila> benws: Yes, but it's not in the IM. It needs to be so that we can include it in the FS
14:23:46 <phila> q+
14:24:14 <victor> to be more precise, we have skos:broaderTransitive
14:24:15 <phila> q-
14:24:29 <renato> :grantUse skos:broaderTransitive odrl:use ;
14:24:58 <Sabrina> we need to check the semantics
14:25:06 <simonstey> we buy in their semantics
14:25:18 <phila> benws: The question is - do we use existing relationships (ie skos:narrower) or define our own
14:25:37 <phila> ivan: SKOS defines it in its own way. Our semantics are a little different.
14:25:45 <Sabrina> if their semantics matches our need then we will reuse, otherwise we come up with a new term
14:25:56 <phila> ... If, as I believe, we need our own semantics, then we should not use SKOS
14:25:58 <simonstey> https://aic.ai.wu.ac.at/~polleres/publications/stey-poll-2015RuleML.pdf
14:26:21 <phila> ivan: The semantics are very specific
14:26:30 <renato> :grantUse  a :Action, skos:Concept ;
14:26:33 <phila> benws: SKOS is not a conflict resolution vocab, and this is
14:26:50 <phila> ivan: It's different
14:27:18 <phila> renato: We use SKOS throughout the ontology so far
14:27:31 <phila> simonstey: We define policy inheritance in a specific way
14:27:51 <phila> ... Which is why we have our own inherit from.
14:27:59 <phila> renato: The community may want us to use SKOS...
14:28:08 <phila> ... Is it not the common way?
14:28:23 <phila> ivan: No because SKOS just relates terms to one another but there are no additional semantics
14:28:38 <phila> ... It's designed for concepts in library hierarchies etc.
14:28:44 <phila> ... This is abstract entities
14:29:14 <phila> 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.
14:29:27 <phila> q/
14:29:29 <phila> q?
14:29:45 <phila> benws: We're talking about what action requires another action, not about terms
14:30:05 <phila> ivan: My understanding is that the hierarchy also includes consequences for the evaluators
14:30:06 <phila> q+
14:30:19 <phila> ack me
14:30:34 <renato> q+
14:30:51 <phila> ack r
14:31:13 <phila> phila: Makes a plea for a different name that just 'narrower' - suggest 'narrowerAction' etc.
14:31:27 <phila> renato: OK, but Serena and I need to know what we are to do.
14:31:41 <phila> ... We'll have to remove SKOS from the ontology
14:31:48 <michaelS> q+
14:31:51 <phila> ivan: Yes, but it's necessasry [Paraphrase]
14:31:54 <phila> ack m
14:32:18 <phila> michaelS: Doesn't this mess up having Use and Transfer as the top level actions
14:33:22 <Sabrina> q+
14:33:27 <phila> simonstey: Those top level ones are required so that you can relate the terms in your profile to the core.
14:33:30 <phila> ack s
14:33:51 <phila> Sabrina: I don't want to complicate, but... we've been focussed on actions but the same applies to assets
14:34:07 <phila> ... What if I'm not allowed to print the Harry Potter book, but I am allowed to print the table of contents
14:34:31 <phila> benws: We discussed being able to apply constraints to assets that, we hope, will cover this.
14:34:44 <phila> Sabrina: That still might lead to a conflict.
14:35:05 <phila> ... A blanket you can't print may or may not be overridden by the constraint.
14:35:20 <phila> Sabrina: It sounds similar to our discussion on the actions but I'll think some more.
14:36:11 <phila> PROPOSED: That we introduce the terms narrowerAction and requiresAction to the Information Model
14:36:30 <Sabrina> q+
14:36:39 <phila> ack s
14:37:23 <phila> 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.
14:37:40 <phila> benws: So... we decide whether we apply the same conflict resolution to assets.
14:37:46 <victor> scribe: victor
14:37:54 <phila> scribeNick: victor
14:38:44 <victor> benws: explains the mechanism we discussed yesterday to impose constraints on assets
14:39:30 <victor> Sabrina: describes a conflict regarding permissions on a book, and one of its pages
14:41:06 <renato> RRSAgent, draft minutes v2
14:41:06 <RRSAgent> I have made the request to generate http://www.w3.org/2017/05/19-poe-minutes.html renato
14:41:08 <victor> simonstey: the preference between permission and prohibition can be expressed, but this mechanism does not solve all the cases
14:43:05 <victor> renato: may make sense, but then odrl is growing and growing.
14:43:26 <victor> benws: we at Thomsom Reuters want ODRL for compliance
14:44:01 <victor> small comment: narrowerAsset is strange; in any case I would term it partOf.
14:45:05 <victor> (phila is back)
14:45:19 <victor> phila: we spoke yesterday about Collections and scope
14:45:45 <victor> phila: how will the semantics will handle constraints on collections?
14:45:59 <victor> simonstey: this has to do with policy merging.
14:46:05 <Sabrina> q+
14:46:51 <victor> simonstey: the ultimate goal is to grab every possible aspect that might be relavant for the conflict detection.
14:47:45 <victor> simonstey: like actions might have other dependencies, etc.
14:48:55 <victor> benws: so you are talking about two properties, essentially the same across assets, actions and parties. Can this be summarized within two single properties?
14:49:16 <victor> s/this/these
14:49:32 <victor> +q
14:49:34 <phila> ack s
14:49:47 <victor> q-
14:50:09 <victor> Sabrina: can be the same property
14:50:22 <victor> Sabrina: although it can be done outside
14:51:39 <phila> PROPOSED: That we introduce the terms odrl:narrowerThan and odrl:alsoRequires to the Information Model
14:51:40 <victor> benws: shall we vote this?
14:51:48 <ivan> +1
14:52:04 <simonstey> +1
14:52:15 <victor> benws: provided that they apply to assets, actions and parties
14:52:25 <phila> PROPOSED: That we introduce the terms odrl:narrowerThan and odrl:alsoRequires to the Information Model. These are applicable to Assets, Parties and Actions
14:52:29 <victor> +q
14:52:36 <victor> -q
14:52:37 <simonstey> +1
14:52:39 <benws> +1
14:52:42 <ivan> +1
14:52:45 <Sabrina> +1
14:53:04 <phila> +1
14:53:15 <phila> RESOLUTION: That we introduce the terms odrl:narrowerThan and odrl:alsoRequires to the Information Model. These are applicable to Assets, Parties and Actions
14:53:17 <renato> +0.9
14:53:41 <michaelS> narrowerThan +0.75, alsoRequires 0
14:53:46 <victor> +0.5 (not this wording, and unsure that an umbrella term can satisfy them all. Also unsure that this should be in the core).
14:54:11 <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//
14:54:38 <renato> and defined !!!
14:54:44 <ivan> q+
14:54:48 <Sabrina> q+
14:54:54 <victor> benws: why dont we ask sabrina and simon to provide a document explaining this in detail?
14:55:36 <victor> ivan: the document should also include the English definition of the meaning.
14:55:52 <ivan> q-
14:55:58 <phila> action: simonstey to send e-mail with relevant text for IM describing the new relationships narrower and requires
14:55:58 <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].
14:56:04 <victor> benws: a presentation would be great in the next call.
14:56:29 <victor> Sabrina: I would like to be there, but I will not be present in the next call
14:57:08 <victor> phila: we should identify the next work items that we have ahead
14:57:54 <victor> phila: it would be nice having a further F2F meeting
14:59:13 <victor> victor: I would like to see a diagram with the relation between profiles, documents, namespaces, etc.
14:59:18 <victor> renato: I can prepare a first version
14:59:55 <victor> benws: AOB? I think we have finished.
15:00:00 <phila> RRSAgent, generate minutes v2
15:00:00 <RRSAgent> I have made the request to generate http://www.w3.org/2017/05/19-poe-minutes.html phila
15:00:12 <victor> benws: thanks to all
15:00:19 <renato> Thanks TR ;-)
15:00:27 <victor> bye bye
15:00:35 <phila> RESOLUTION: Thanks to Ben and TR for hosting the meeting
15:00:55 <phila> RRSAgent, generate minutes v2
15:00:55 <RRSAgent> I have made the request to generate http://www.w3.org/2017/05/19-poe-minutes.html phila