[Minutes] 2016-04-25

After some mucking around and rescuing of early parts of the meeting 
from Ivan's IRC log, the minutes of today's meeting are at
https://www.w3.org/2016/04/25-poe-minutes

Discussion today focused around the number and content of our 
deliverables (general agreement). Whether model document would also act 
as a Primer (which we really could do with producing one way or 
another). And then the more vexed question of whether the JSON encoding 
should just be the JSON-LD encoding minus the @context file or whether 
we'd define more JSON developer-friendly terms and then use the context 
file to map to the more RDF-friendly terms.

Text version of the minutes below.


   Permissions and Obligations Expression Working Group Teleconference

25 Apr 2016

    [2]Agenda

       [2] https://www.w3.org/2016/poe/wiki/Meetings:Telecon20160425

    See also: [3]IRC log

       [3] http://www.w3.org/2016/04/25-poe-irc

Attendees

    Present
           ivan, renato, phila, michaelS, Serena, mmcrober, smyles,
           victor

    Regrets
           jo, sabrina

    Chair
           Ben

    Scribe
           ivan

Contents

      * [4]Topics
          1. [5]our deliverables
      * [6]Summary of Action Items
      * [7]Summary of Resolutions
      __________________________________________________________

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

       [8] https://www.w3.org/2016/poe/wiki/Scribes

    <scribe> scribenick: ivan

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

    <phila> [9]Last week's Minutes

       [9] http://www.w3.org/2016/04/18-poe-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> [10]https://www.w3.org/2016/poe/wiki/Deliverables

      [10] 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> [11]http://w3c.github.io/poe/model/WD/

      [11] http://w3c.github.io/poe/model/WD/

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

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

      [12] 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...

Summary of Action Items

Summary of Resolutions

    [End of minutes]
      __________________________________________________________



-- 


Phil Archer
W3C Data Activity Lead
http://www.w3.org/2013/data/

http://philarcher.org
+44 (0)7887 767755
@philarcher1

Received on Monday, 25 April 2016 13:42:22 UTC