W3C

Permissions and Obligations Expression Working Group Teleconference

05 June 2017

Meeting Minutes

<renato> Is all of Europe on holidays?

<ivan> well, most of it

<ivan> but... the meeting is marked to be cancelled?

<renato> I am ok to cancel it

[General discussion about whether there are sufficient people for a meaningful meeting]

benws11111: Not enough people IMO
… Can we clarify some dates - when are we next looking to publish

renato: The next milestone is to go to CR

renato: Got to get things lined up for that

renato: In theory, it was going to be at the F2F but we weren't close to resolving the outstanding issues.
… No new target set as yet
… My my POV, I can see maybe another couple of weeks for the 2 deliverables, then the test cases

ivan: We have a plan for how to do the test cases?
… If we have a plan and say they'll be complete shortly.
… Going to CR doesn't need all the test cases to be in place

<CarolineB> *me sorry to be late

benws11111: When we go to Rec, we're going with 2 documents?

[Yes]

benws11111: benws11111 What will be the status of the Vocab?

ivan: Recommendation

benws11111: It's going to be quite small though isn't it?

renato: Not too small.

benws11111: So if they go into the Rec process, does that mean the UCR needs to be in its final form

ivan: There's no process requirement on the UCR

ivan: It's usually closed at the end of the process. Might want to make some final bits to the UCR to point to where Recs are met

phila: Outlines different assumptions about what an ODRL Evaluator returns and therefore what inputs it needs

benws11111: It makes sense that an agreement or offer is in effect, not sure what a Set being in effect means

<victor> different blackboxes will need different inputs/outputs.

Yes, I am defining an API, ivan

<renato> http://‌w3c.github.io/‌poe/‌model/#constraint-party

[Discussion about what a black box and an evaluator needs to know]

<benws11111> +1

ivan: We don't need to standardise the behaviour of the black boxes
… Each implementation has to answer the questions Phil is asking, but they can do it as they wish

benws11111: The policy evaluator is, given these inputs from the black boxes, is this policy in play or not

renato: Do you mean policy or Rule

benws11111: Rule

renato: If there were a Rule with 6 constraints, do we say give me a true or false for all of them?

benws11111: Describes a black box per constraint. Get back all the answwers

<victor> You can play this on Tuesday. BLACKBOX1: "I need the current time". BLACKBOX2: "I need the current time and the party's location, to determine whether in his/her location we are already on Tuesday". Specific implementations need different params, but cannot standardize that --> black boxes should be very black

renato: All need to know that all constraints are satisfied for the Rule to be in force

benws11111: We'd need a different charter to handle the kind of processing Phil's talking about

ivan: We're defining a vocabulary, no more

ivan: We'd need a market for black boxes.

[AOB]

benws11111: Not asking for accepting minutes etc. as not quorate this week. Will pick up next week.

ivan: How close are really to a CR?

ivan: I'm a little worried that the F2F had to discuss pretty heavy technical issues that are still not closed.
… I saw the Renato/Michael discussion this morning

benws11111: We did make those tech decisions, I think.

ivan: The SKOS/Not SKOS discussion is about whether we have additional semantics on those terms.
… If so, then those semantics need to be properly defined and put in the doc.

benws11111: I would say the semantics are up to the formal semantics editors

ivan: But the semantics have to be reflected in the Rec Track doc. The Semantics doc isn't Rec Track.
… Something has to go into the model and vocab that is binding.

renato: The 1st attempt to define narrowerThan and implies didn't work but that's always the way. We need to clarify that these are not SKOS-like
… Then in for FS doc, we provide the maths

renato: I think we just go through the usual collaborative process. Say that we're not going to use SKOS for those. We can still use it for concepts

ivan: But what does it bring that SKOS doesn't have?
… Not sure what it brings to have it.

ivan: If people are happy, I'll be quiet.

renato: Did the Annotations WG use SKOS?

ivan: No.
… I think we had a brief discussion, but when SKOS came around, this kind of confusion about the role of SKOS came up.

benws11111: I can fall into that confusion easily.
… It loses relevance as you move on to ontologies
… There's value where you want a term to come from a controlled vocab but that's not what we're doing with these 2 new properties.

ivan: I wonder whether, every appearance of SKOS, in the current version, is right.

benws11111: Not to control hierarchy, but for a taxonomy.

ivan: I hope I'm right that the use of SKOS isn't part of the model or vocab?

renato: Intentionally there for a reason?

ivan: Is it part of the spec or is it only in the ontology?

renato: It doesn't appear in the human-readable doc

ivan: I'm guessing that the use of SKOS is not part of the normative part of our Rec Track docs

renato: True

ivan: So if in CR, someone take the time to look at and clean up the ontology, then it can be done without breaking CR.

<victor> can that be rephrased again?

ivan: Whether we have the time and will is another matter.

ivan: I could say that the ontology for the normative vocab, should not contain any term which is not specified by the standard.

ivan: We have an ontology. That's not the Rec.
… Any RDF statement in that ontology that is extra, it's an extra that no one in the WG voted on

renato: we can put SKOS axioms in the ontology, but they don't really change things

benws11111: we should reflect the Rec in the ontology

ivan: Yes.

victor: We have info in the ontology that isn't in the Rec

ivan: The ontology is clearly specified...

[Victor shows diagram with Venn diagram of English language Spec and OWL file]

victor: I wonder whether other ontologies have been specified like this

phila: Talks about DCAT. The Rec mandates the use of DC Terms in various places, the namespace file doesn't mention any term other than dcat: terms

benws11111: we'll have to discuss it in ore detail when we're quorate.

[Informal resolution]

The ontology (namespace file) should only include terms defined in the Rec Track document

ivan: We talked about the core/common vocab.
… New terms may be in non-normative parts of the Rec Track doc, they can be included. But there shouldn't be terms that are not mentioned anywhere in the Rec

renato: We've already removed the SKOS terms
… We used to use things like skos:definition, skos:scopeNote etc.

ivan: RDF has label and comment

phila: I would use dcterms:description if rdfs:comment is insufficient

renato: We took out all the skos:broaderTerm stuff

ivan: But Michael isn't happy?

renato: He wants to use SKOS for broader/narrower
… We need to articulate the difference
… I think we should change the name from narrowerThan to ??

phila: ?? suggests 'refines/refinementOf'

benws11111: How about 'assumes'

ivan: Let's wait fort Simon

renato: That would help to explain why we have our own terms

ivan: So we used our time wisely after all?

benws11111: Not bad for an informal chat.