Permissions and Obligations Expression Working Group Teleconference

<renato> https://www.w3.org/2016/poe/wiki/Scribes

<scribe> scribenick: ivan

benws: first discuss our deliverables
... oops, approve minutes first

<phila> Last week's Minutes

<phila> PROPOSED: Accept last week's minutes

+1

<phila> +1

<Serena> +1

<benws> +1

<michaelS> +1

<smyles> +1

<renato> +1

RESOLUTION: Accept last week's minutes

<victor> I am afraid I have a very poor connection today (out of my office) and I am unsure if I can fully participate in the call, but will try my best

our deliverables

renato: we have charetred to deliver 2 notes and 5 recs

<benws> https://www.w3.org/2016/poe/wiki/Deliverables

renato: use case is a note and the formal semantics is also one
... 5 recs are the current cg reports
... looking at those
... the inf model is straightforwards in more or less in that form
... the vocab and the ontology have an overlap
... the ontology provides the owl/rdf replicates the vocab terms
... then we have the other two, xml and json encoding
... looking at those without teh examples there is not much normative texts
... they are not long normatively
... what I looked at to merge these together
... to make more sense within the Rec model at W3C

<renato> http://w3c.github.io/poe/model/WD/

renato: this is a hypthetical doc of the model ^
... the key is the vocab part

<renato> http://w3c.github.io/poe/vocab/WD/

renato: my proposal is that the new vocab merges the vocab, ontology and encoding specs
... another URL ^ is a bare bones version of what could be done
... looking throught he document is, in sect. 2, explain the vocabulary, and different sections on the model and constraints etc.
... on each policy (2.1.1.) you have a human readable semantics, and underneath is the ontological representation,
... section 2 would cover all current vocab and ontology
... in section 3 there is an encoding
... in the scenarios I copied the examples from another w3c spec, with tabs
... you can see the various encoding scenarios, we can have them all
... of course the examples could be put back to section 2

<trackbot> Meeting: Permissions and Obligations Expression Working Group Teleconference

<trackbot> Date: 25 April 2016

renato: the short is my proposal is to develop 2 recs: model and vocabulary+expression document
... and follow the model that I followed
... if we get stuck somewhere by doing that we can go back to another format

smyles: i was one of the editors of json spec
... it is the case that we took the xml spec and modified it
... to be the same thing except json
... so it is not suprising there is no much difference
... it makes sense to bring together the way renato outlines
... one thing we have to work through is discussing how we want to support json-ld
... we designed our json spec is not json-ld
... but the rdf model can be expressed in json-ld as well as xml

+1 to json ld

mmcrober: the rdf version was produced the same way as the json
... i would be definitely be in favour of merging
... the layout is quite nice
... it could actually generate what is there from the tool that generates the ontology document

<victor> +1 to json ld. This would favour the POE adoption by developers

mmcrober: with minimal changes
... the only problem may be as a developer the separate between the model and the vocabulary is necessary useful
... if we are the point of a decision, we may consider whether we need two deliverables or a single one

phila: mmcrober, you are actually proposing to have one document

smyles: I agree it will make it easier for adoption if there is only one document
... it makes it simpler
... one fo the reasons the vocab is separate is that it means that people who are interested in the model but need their own expressions are encourged to create their own vocabulary
... eg, iptc developed our vocabulary
... the process developing that vocabulary led to lots of comments to the cg
... so we are happy with the current vocabulary of odrl
... we would be fine be one
... but the separation of the model is one of the strength

renato: about merging even more, but, as smyles said, we wanted the separation
... we wanted to be able to refer to the model only
... a community may say is interested the model only
... that was the discussion 10 years ago :-)
... today developers may like everything in one place
... I can see the advantage of one spec
... an advantage of a separate model is that it almost reads like a primer
... it has narrative way of presenting things

<mmcrober> would a compromise perhaps to be to merge, but to call out the extensibility/profiling as a key feature perhaps in the documents?

renato: I can see both

phila: I do not have a strong opinion on the number of recs
... the issue of a primer did come up, and we do need to have a primer

<victor> +1 to renato's idea that ODRL's strength stems from the clear separation between model and vocabulary(ies).

<renato> +1

phila: if it makes sense to have it as part of a model
... or in a ucr, that is also o.k.

<renato> +q

phila: but we do need a primer

benws: in defense of splitting...

<phila> acn r

benws: odrl was attractive to the iptc for a different model
... although in the iptc it converged
... but I was working on a profile for stock exchanged
... where the language is very different
... and that usage would be very specific
... the separation is very helpful for that

renato: on the primer: we could definitely have to put it into the plans
... once we got the documents on the rail, make a decision based on that

phila: json was not quite the same as the RDF
... in my head json-ld should be the json encoding, the only difference being using or not @context

<james> +1 phila

<mmcrober> yes

<Zakim> phila, you wanted to ask about diff between ODRL JSON and ODRL JSON-LD and to ask about diff between ODRL JSON and ODRL JSON-LD

smyles: the reason we did not make a json ld version is because we felt that for some developers having json ld is attractive, for some it is awkward

<mmcrober> er

smyles: people who just want to do json we felt they would be confused by doing anything extra
... we tried handcraft in a way that was natural for somebody only on json
... the same way rdf can be used to generate xml, not like rdf/xml
... you could do a json

s/simnostey:/smyles:/

mmcrober: obviously echoing the point json not equal json-ld
... do we want to have a json-ld expression
... what happens with the current json expression? Deprecate?
... we could give a major version step
... that would allow on the flexibility without calamitous effects
... we have to agree with what we do
... I am semi-ambivalent about this
... the json expression modeling is slightly different from the xml
... the rdf expression has a bit of an extra latitude
... it allows the requirements of json

benws: we are fairly json friendly in the naming

mmcrober: yes, and a smart use of @context goes a long way
... a json-ld version could be created that is very close to json

<james> graph can be a bit weird

mmcrober: there might be some interesting nuances in the way certain things is expressed for friendliness to json users
... it is not always necessarily be the natural expression of a javascript developer
... is a json-ld version sufficiently useful on its own right
... or having round-trip is useful or not useful
... there are already minor differences

<james> yes

james: we use odrl json and json-ld
... also some ui work using this
... we are a json platform, we pass around rdf/xml
... we go json-ld to json
... using @context, which is a powerful stuff
... my preference is not to have handcrafted stuff
... we would response by default in json
... I would say json is good enough
... it becomes tricky when tehre are different objects referring to multiple spaces
... preference is to use @context to transform one to the other

benws: you say we should publish only json-ld or both?

james: if we publish a recommended @context, then I would be happy with

<phila> I like what James is saying - JSON/JSON-LD would only differ by inclusion of the @context

<phila> ivan: On JSON-LD...

<michaelS> my mic doesn't work wait a second please

<victor> i don't have a strong opinion on this issue.

<Serena> I don't have a strong opinion either.

<phila> ... We need to realise that by defining the RDF vocab, we have JSON-LD

<phila> ivan: The question therefore whether we need an additional JSON encoding.

<phila> ... I've been through this discussion in CSVW and Annotation, we firmly decided to use JSON-LD only

<phila> ... ANd tried to make heavy use of what @context can do - which is a lot.

<phila> ... In Annotation, the terms used in the formal spec are very differnet from the one is JSON because hasX is unfriendly to JSON people, so we renamed them

<phila> ... and used context to take crae of that mapping.

<phila> ... Lots of dicsussion of @id or id

<phila> ... Context can go a very long way.

<phila> ... Only feature that we didn't have in the Annotation model, where JSON-LD is awkward, if you have a structure that is not tree-like but where there are 2 portions with diff RDF subjects

<phila> ... in JSON-LD you have to go through some @graph construct that is awkward.

<phila> ... Apart from that, JSON-LD 9minues @context) is JSON. Done

<phila> ... Message we give, if you don't care about the RDF vocabs, you use our JSON. If you do care, you add the @context statement

<phila> ... So for us it worked. One step further... in the annotation work, we went one step further.

<phila> ... We also have a model and a vocab document.

<phila> ... The model document has a kind of a Primer feeling to it.

<phila> ... All the examples are in JSON so a JSON user can take hte model doc and go from there. The vocab doc may havea JSOn-LD etc.

<phila> ... SO we went even furtehr than what Renato proposed. Just saying what other WGs have done

<scribe> scribenick: ivan

michaelS: we have created something like that
... with json that can be used with or without @context
... having a quick look at the current json
... there are some properties in the json which are properties with a qualifier in xml
... they ahve been merged in one entity in json
... ahve an identifiers for that
... if this can be done

<renato> I like RDF/XML ;-)

<Serena> :-)

<james> There is always one!

<mmcrober> of course, if we agree to align around RDF + JSON-LD (which is polymorphic plain ol' JSON, essentially), the question is then whether the XML should be expressed as a transform from the RDF as well (e.g., XSLT from the RDF/XML...)

<victor> having a few javascript functions converting expressions from RDF/XML (that nobody likes ;-) ) - JSON - JSON-LD would make this debate unnecessary. At least a subset of the expressible policies might be easily handled and everybody would be happy.

smyles: there are implementations, including AP's, that are primarily json
... it would be disappointing if my organization has to alter json

benws: is that an argument against versioning or json-ld only?

smyles: I do not know...
... for me it would be problematic to say we have changed things

benws: the quesiton is: would they have to change anything if there was a graceful degradation

smyles: of course if there was just a possiblity to add @context, that would work

benws: i assumed that we would have a json standard without @context

<mmcrober> degredation = the future JSON-LD serialisation of the RDF, but without @context, is completely compatible with the ODRL 2.x JSON expression

<simonstey> -q postpone discussion on ODRL profiling + different ODRL recomm. to next week

<simonstey> -q

<simonstey> postpone discussion on ODRL profiling + different ODRL recomm. to next week

<benws> Two options: we maintain both a json and json-ld standard - but document only JSON-LD and say we get the jSON standard by removing the context OR we only recommend JSON-LD

<phila> ivan: Do you mean the JSON encoding as it is today, or for whatever comes later

<phila> benws: The latter

<phila> ivan: In that case, for practical purposes, I don't see a difference between the two options

<phila> ivan: Anyone can use JSON-LD without the context

<phila> benws: But Stuart is saying that if we just recommend JSON-LD then the JSON is likely to be differnet?

<phila> smyles: It's because there woujld be diffrences between the current and future JSON without the @context.

<phila> ... The lack of conformance in our workflow would be a problem.

<james> +1 ivan

<phila> ivan: So if we forget about JSON-LD, I don't think we can make a commitment that what we do will have a JSON encoding that is the same as the current ODRL.

<phila> smyles: And the same would go for the other encodings

<phila> ivan: This is orthogonal to the JSON-JSON-LD question

<mmcrober> IOW, alignment between expressions will necessitate changing them - how much of a problem is this?

benws: should we put this on the vote now?
... will me make a JSON-LD rec (and a JSON would just be without @context)

<mmcrober> +1 renato

renato: it needs more talks offline

+1 to renato

phila: the @context has lot more power than just adding a URL
... it may be possible to use it for more things

smyles: we need to look at providing guidence to people using ODRL with encoding of any type

phila: that would be an important piece of work
... you may have a choice of context files

benws: we ran out of time
... we have not covered everything but this discussion has been important
... we looked at moving down to 1 or 2 documents, there was many in favour
... the other is json-ld vs. json

phila: we appreciate Renato being on the call on ansac day:-) but we have no meeting next week due to uk holidays

serena: I work at CNRS for Fabien Gandon,
... I work on ontology for legal documents
... and how to express legal documents in a machine readable formats

<james> Thanks

benws: adjurned...