- From: Phil Archer <phila@w3.org>
- Date: Mon, 25 Apr 2016 14:41:27 +0100
- To: W3C POE WG <public-poe-wg@w3.org>
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