JSON-LD Telecon Minutes for 2013-07-02

Thanks to Niklas for scribing. The minutes from this week's telecon are
now available.

http://json-ld.org/minutes/2013-07-02/

Full text of the discussion follows including a link to the audio
transcript:

-------------------------------------------------------------------
JSON-LD Community Group Telecon Minutes for 2013-07-02

Agenda:
   http://lists.w3.org/Archives/Public/public-linked-json/2013Jul/0000.html
Topics:
   1. Assigning Properties to Lists
   2. GSoC update
   3. JSON-LD / RDF Alignment
   4. Lists in the JSON and RDF data models
   5. Default interpretation of JSON arrays
Resolutions:
   1. Create an issue in the RDF WG to formalize a way to express
      lists that need to be identified with a URL and annotated using
      properties.
Chair:
   Manu Sporny
Scribe:
   Niklas Lindström
Present:
   Niklas Lindström, Robert Sanderson, Markus Lanthaler,
   Manu Sporny, David Booth, David I. Lehn, Vikash Agrawal
Audio:
   http://json-ld.org/minutes/2013-07-02/audio.ogg

Niklas Lindström is scribing.

Topic: Assigning Properties to Lists

Markus Lanthaler:
   https://github.com/json-ld/json-ld.org/issues/75
Robert Sanderson:  we'd very much like to give rdf:Lists
   identity, so that they can be referenced from multiple graphs.
   Also to describe them with other properties
   ... in openannotation, we need lists to define a selector
   which determines which part is annotated
   ... for instance, which piece of a text is annotated, with
   "before" and "after" also recorded (most clients work like that)
   ... Futhermore, IDPF has agreed to use openannotation for all
   EPub books
   ... EPubs, being zip files with a bunch of files
   ... To define a selector here (take the EPub, select a file,
   then a part in there)
   ... So we don't want to reproduce every single selector
   mechanism. Thus, an ordered list of two selectors would be
   neeeded.
   ... We thus need to identify lists, so that we can reuse these
   selectors in multiple statements.
   ... I.e. a person wants to disagree with a specific
   annotation, or place being annotated.
   ... Furthermore, we have the order of multiple targets, e..g.
   "the first passage on page three, is derived from the second
   passage on page five"
   ... Not as essential, since it's not really machine actionable
   ... Another project using lists is Shared Canvas
   ... We'd very much like to use JSON-LD there too, for
   selecting pages, using a list of pages and so forth
   ... For this, we took the "list items" approach; the list
   doesn't need to be referenced directly.
Markus Lanthaler: robert, do you have the link of an example at
   hand?
   ... But it might be nice to have this standardized, so people
   don't reinvent list items all the time.
   ... at the mailing list and also the OA community meeting in
   Europe, we agreed that we don't want to change the model to
   accomodate different syntaxes
   ... We want to recommend JSON-LD
Manu Sporny:  what's the timeline for these needs / when would
   the WG close
Robert Sanderson:  at the moment, the CG is in an implementation
   phase. We need to dicuss with Ivan, but we hope to move from CG
   to WG next year
Manu Sporny:  we're very close to CR in JSON-LD. If we'd add his
   feature in, it would put us back for many months. Could we add
   this for JSON-LD 1.1?
   ... If we think we can put the feature in, I think we can
   easily convince implementers to add it. If we add it to the test
   suite, other implementers would add it.
   ... So for practical purposes, we aim for it to be added
   within a year or so.
Robert Sanderson:  Yes, that approach could work for us. Given
   that your'e much further ahead. It's not our prefered option,
   since for implementations, it might be unpredictable.
   ... Also, changing this for OA now is much easier than when in
   a WG
   ... I don't believe anyone has implemented it yet, but IDPF
   needs this to be implementable
Manu Sporny:  so we may put it in jSON-LD 1.1
Niklas Lindström:  First thing, as far as I know, Turtle doesn't
   support this syntax either. Given that you have a shorthand in
   Turtle.... actually, none of the formats in RDF/XML and Turtle
   support this sort of list syntax. [scribe assist by Manu Sporny]
Markus Lanthaler: niklasl, AFAICT they currently set rdf:rest to
   a Turtle list
Niklas Lindström:  Have you discussed that as well? Am I missing
   something? [scribe assist by Manu Sporny]
Robert Sanderson:  No, I don't think you missed anything. [scribe
   assist by Manu Sporny]
Robert Sanderson:  The identity is easier in RDF/XML - you have
   the property for the URI. [scribe assist by Manu Sporny]
Robert Sanderson:  We did consider the other serializations, it's
   not a ubiquitous feature, but it would be nice to have in
   JSON-LD. [scribe assist by Manu Sporny]
Niklas Lindström:  Right, the main argument when we had the
   issue, even though it's in the Primer that says there is nothing
   preventing lists from being described, multiple start properties,
   etc. None of the core syntaxes allow it, it's not intended to be
   used like that. [scribe assist by Manu Sporny]
Niklas Lindström:  They're supposed to be used as syntactic
   constructs.... model-wise, they're not really a part of RDF.
   [scribe assist by Manu Sporny]
Niklas Lindström:  If this is supported in JSON-LD, it would be a
   lot easier to deviate from the recommended usage pattern.... also
   making it harder for a future RDF spec, who wants to add lists as
   a native part of the model [scribe assist by Manu Sporny]
Niklas Lindström:  You can still use rdf:first / rdf:next
   explicitly today. [scribe assist by Manu Sporny]
Robert Sanderson:  I agree. The notion of order in a graph is
   always problematic. Not the common method to have a resource that
   is a list and has identity. [scribe assist by Manu Sporny]
Robert Sanderson:  Maybe RDF COncepts 1.1 should discuss it.
   [scribe assist by Manu Sporny]
David Booth:  Yeah, RDF WG should consider this. I agree with
   Niklas. It doesn't fit w/ the usual list pattern. Important to
   consider implications. [scribe assist by Manu Sporny]
   ... Here's an example:
   http://www.openannotation.org/spec/core/multiplicity.html#List
Robert Sanderson: That's it exactly, thanks Niklas1
Manu Sporny:  any other thoughs on this?
Markus Lanthaler:  it would make it hard to expect compaction to
   behave as predicted
   ... also, compaction might be more complex
Manu Sporny:  Yes. We wanted to stay away from it since it might
   be a mine field in general.
   ... that said, there might be a case for this.
Niklas Lindström:  Agree with Manu's point - there might be
   something new that's interesting here. I don't think we should do
   it w/o discussing implications. Algorithmic complexity for
   JSON-LD API and implementations. It might be almost as
   problematic as bnodes as predicates. It's possible to do this in
   raw RDF. It seems highly obvious that you can add ID in other
   properties. On the other hands you... [scribe assist by Manu
   Sporny]
Manu Sporny: ...can do it w/ literals.
Niklas Lindström:  This borders on the syntactical collapse.
   [scribe assist by Manu Sporny]
Markus Lanthaler:  syntactically having a property carrying the
   actual list is nearly indistinguishable as the requested form
   (using "@list" as key)
Robert Sanderson:  I agree. The easisest solution for everyone
   would be to have a "listItem" as a property.
   ... and for the RDF WG, it might be good to define a dedicated
   predicate for it. rdf:value is explicitly fuzzy, so you can't
   always expect a list.
David Booth: Robert, would it be feasible to just wrap the list
   in another object, and attach the additional info to the wrapper
   object? (I apologize that I have not fully grokked the problem,
   so this suggestion may not be helpful.)
   ... It would be easier to sell changing the model if there was
   another predicate for this.
Manu Sporny:  so a specific vocabulary for lists would be
   beneficial in general, working in all syntaxes
   ... would that adress this issue? If we quickly create a list
   vocabulary?
Robert Sanderson:  I think so. Not preferable duing the
   discussions we had, but the syntactic arguments may sway this
   position.
   ... A single, interoperable solution is preferable.
Manu Sporny:  anyone objects to open issue 75, to continue this
   dicussion?
Niklas Lindström:  I think we should try to have this as an RDF
   issue - it really would not come up if lists were core to the RDF
   model. It's a sore spot in RDF Concepts. I think we should push
   it over to the RDF WG immediately. It's arbitrary if we or OA try
   to push something forward, it won't solve the real problem....
   not in rdf schema vocab. [scribe assist by Manu Sporny]
Robert Sanderson: +1 to Niklas

PROPOSAL: Create an issue in the RDF WG to formalize a way to
   express lists that need to be identified with a URL and annotated
   using properties.

Manu Sporny: +1
David Booth: +1
Robert Sanderson: +1
Niklas Lindström: +1 could be someything like rdf:listValue
David I. Lehn: +1
Markus Lanthaler: +1

RESOLUTION: Create an issue in the RDF WG to formalize a way to
   express lists that need to be identified with a URL and annotated
   using properties.

Topic: GSoC update

Vikash Agrawal:  what's broken in the playground?
Manu Sporny:  a bit weird ui paradigm when clicking on expanded
   form; headings for JSON-LD Context stay, but the input box
   disappears.
Markus Lanthaler:
   http://www.markus-lanthaler.com/jsonld/playground/
Markus Lanthaler:  the headers stay but the inputs disappear.
   Previously headers were toggled off if input areas weren't
   applicable
Manu Sporny:  play around a bit. I think the old way is better.
   There may be something even better, but right now, the problem is
   that something not used is still shown.
Vikash Agrawal:  this is bug 50
   ... by this week, this should be done. Next week is a creator
   app.
Markus Lanthaler: could we discuss these things on the mailing
   list or the issue tracker?
Manu Sporny:  email danbri and gregg regarding a schema.org
   JSON-LD context
Markus Lanthaler: vikash, here's Sandro's schema.org context:
   http://www.w3.org/People/Sandro/schema-org-context.jsonld
Markus Lanthaler: for the creator app, have a look at:
   http://schema-creator.org/

Topic: JSON-LD / RDF Alignment

Manu Sporny:
   http://lists.w3.org/Archives/Public/public-rdf-wg/2013Jun/0233.html
Manu Sporny:  I went into the spec and tried to integrate what we
   have consensus on.
   ... see the email link above for a list of things.
   ... everything should be there except for skolemization
David Booth:  I just found it, but I think it looks great (just
   some minor things)
Manu Sporny:  would it adress the LC comment?
David Booth:  It might. It's in the right direction.
Manu Sporny:
   http://json-ld.org/spec/ED/json-ld/20130630/diff-20130411.html#data-model
Manu Sporny:  next, Peter's changes. Appendix A was changed to
   flat out say that JSON-LD uses an extended RDF model.
   ... we just say "Data Model", and that it's an extension of
   the RDF data model.
Markus Lanthaler:
   http://lists.w3.org/Archives/Public/public-rdf-wg/2013Jul/0010.html
   ... we need to have a resonse from Peter on this.
David Booth:  I'd expect it to be, to the extent that I can
   channel Peter.
David Booth: Every node is an IRI , a blank node , a JSON-LD
   value , or a list .
David Booth:  restricting the literal space to JSON-LD values is
   a restriction rather than an extension to the RDF model.
Robert Sanderson: Sorry, have to attend another call now, though
   would like to have stayed for the rest of the conversation.
   Thanks everyone for the discussion re lists.
   ... and I don't think that lists need to be mentioned there;
   they are just sugar.
Markus Lanthaler: "A JSON-LD value is a string, a number, true or
   false, a typed value, or a language-tagged string."
Markus Lanthaler: thanks for joining robert
Manu Sporny:  on top, we extension the value space to json true
   and false, numbers and strings.
David Booth: A JSON-LD value is a string , a number , true or
   false , a typed value , or a language-tagged string .
David Booth:  it wasn't clear that those lined up with the
   corresponding RDF value space.
Manu and David agree that the JSON number value space is more
   general.
Manu Sporny:  different lexical spaces for booleans in xsd and
   json

Topic: Lists in the JSON and RDF data models

David Booth:  What about lists, aren't they the same as expressed
   in RDF?
Manu Sporny:  not convinced that they are..
   ... we need to translate it to something in the data model. In
   RDF, it translates to the list properties. There is nothing in
   RDF concepts to point to.
   ... many just assumes that it's basically part of the data
   model, but it's formally not
David Booth:  why not point to rdf schema?
Manu Sporny:  not part of the rdf data model.
Niklas Lindström:  Yeah, just a comment. Could we correlate this
   RDF Concepts problem w/ the suggestion wrt. list values. [scribe
   assist by Manu Sporny]
David Booth: RDF lists:
David Booth: http://www.w3.org/TR/rdf-schema/#ch_list
Niklas Lindström:  Clearly, lists are under-specified. [scribe
   assist by Manu Sporny]
Niklas Lindström:  Maybe we should expand RDF Concepts that is
   present in the 2004 Primer and the Syntax that I scanned
   previously. [scribe assist by Manu Sporny]
Manu Sporny:  but does rdf schema extend the rdf data model?
David Booth:  no, just a convention which is using the rdf data
   model
Markus Lanthaler:  but's still just a vocabulary. In JSON-LD, we
   use [a keyword and] an array
   ... it's like a node type [just as literals]
Manu Sporny:  the JSON-LD data model does not talk about
   rdf:first and rdf:rest
David Booth:  I don't think any test cases needs to be changed by
   the way this is described. So it's just a question of how this
   concept is being described. At present, it's described as a
   difference.
Manu Sporny:  True. We only change how you think about the data
   model.
Manu Sporny:  if we make an argument about the difference between
   native JSON literals and RDF literals, we need to explain the
   difference of expressing lists as well.
David Booth:  I don't see the benefit as a difference, from an
   RDF perspective.
Niklas Lindström:  I think I can answer re: benefit of having
   different model wrt. JSON lists and RDF lists. In JSON, there are
   arrays, those arrays represent repeated statements in RDF>
   [scribe assist by Manu Sporny]
Niklas Lindström:  RDF people understands that intuitively. We
   mention @set because people that don't understand RDF, but do
   understand mathematical sets.... ordered list is more popular
   than sets in programming. [scribe assist by Manu Sporny]
Niklas Lindström:  We need a way to explain lists in JSON-LD, in
   the same way that we explain sets, and other things. Not in a way
   that introduces rdf:first and rdf:next. [scribe assist by Manu
   Sporny]
David Booth: Bottom line: I do not see a need to call out lists
   as being a difference from the RDF model, but I'm okay with it
   being mentioned, in part because I'd like to push RDF to have
   native lists.
Markus Lanthaler: manu, did you see
   http://lists.w3.org/Archives/Public/public-rdf-wg/2013Jul/0010.html
   already?

Topic: Default interpretation of JSON arrays

David Booth:  it seems strange to have @set (unordered) as the
   default
   ... in regular json, the default is ordered
Markus Lanthaler:  We discussed this quite a bit in the
   beginning, the rationale was that the RDF that was generated
   would be unmanageable - lots of blank nodes, lots of
   rdf:first/rdf:rest, you couldn't work w/ the RDF anymore. [scribe
   assist by Manu Sporny]
Markus Lanthaler:  we discussed it quite a bit in the beginning.
   The rationale we came up with is that the generated RDF would be
   very gruesome, using rdf lists for everything.
   ... hundreds of blank nodes for everything.
Niklas Lindström:  Yeah, I agree. That's the rationale. While
   it's true that arrays in JSON are ordered in their nature, in all
   the JSON-LD examples, they are commonly only sets. There is no
   real order. JSON-LD is intended to be used w/ RDF properties,
   there are only a handful of common RDF properties - author,
   contributorList, propertyChainAction, where the order is
   semantic, it means something. [scribe assist by Manu Sporny]
Niklas Lindström:  In every other case, it's just a bundle of
   things. I think that's the better case - explicitly say order
   doesn't mean anything. The same thinking has obscured lots of
   things wrt. XML. You can rely on the order of the elements, not
   sure if you should. It's better to say that "you can't rely on
   the order", unless someone says so explicitly. [scribe assist by
   Manu Sporny]
David Booth:  As a programmer, I'd use the exact opposite
   rationale. [scribe assist by Manu Sporny]
David Booth: So if the default were changed to being ordered,
   then the examples would have to be changed to add @set?
Markus Lanthaler:
   https://github.com/json-ld/json-ld.org/issues/12
Niklas Lindström:  We discussed whether we should do it in the
   @context, we could define @set to be the default. [scribe assist
   by Manu Sporny]
Niklas Lindström:  I agree w/ David that as a programmer, you
   think like that. Unless you think otherwise. [scribe assist by
   Manu Sporny]
David Booth:  There is also minimal changes going from JSON to
   JSON-LD. [scribe assist by Manu Sporny]
Niklas Lindström:  Datasets on the Web, you never know if the
   order is intentional or not. It's better to assume that it's not
   ordered. [scribe assist by Manu Sporny]
Markus Lanthaler:  JSON-LD can already serialize the same data in
   so many ways already - remote contexts, you can't really
   interpret the data anymore by just looking at it. Maybe doing it
   in a processor flag, but not in the context. [scribe assist by
   Manu Sporny]
Niklas Lindström:  I'd like to be able to do this in the context.
   "@container": "@set" would be useful to me. [scribe assist by
   Manu Sporny]
David Booth: Can we have a global way to indicate @set ?
Niklas Lindström:  Yeah, but I could wait for this feature.
   [scribe assist by Manu Sporny]
David Booth:  I'm worried about the element of surprise. It
   reverses the common expectation.
Manu Sporny:  It has not come up as a real issue from anywere
   though.
Markus Lanthaler:  Is there a use case for this? [scribe assist
   by Manu Sporny]
Markus Lanthaler:  In the majority of instances, the order is
   irrelevant
David Booth:  yes, quite possible
Manu Sporny:  a change could also backfire at this stage
   ... we could potentially have a JSON-LD 1.1, for e.g. this.
David Booth: I think the best solution would be a simple global
   way to specify @set, and user get used to always doing that.
Niklas Lindström:  I think that it can't fly from my point of
   view - given that for every case where I've seen order having
   meaning, it's always been a very specific technical reason.
   Implicitly ordered things as properties on the object. In every
   specific scenario where order is used.... [scribe missed] [scribe
   assist by Manu Sporny]
Niklas Lindström:  check out schema.org· only a handful where the
   meaning is explicitly ordered:
   http://www.w3.org/People/Sandro/schema-org-context.jsonld
Niklas Lindström:  I might be open that it should be ordered, but
   not by default. [scribe assist by Manu Sporny]

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
Founder/CEO - Digital Bazaar, Inc.
blog: Meritora - Web payments commercial launch
http://blog.meritora.com/launch/

Received on Tuesday, 2 July 2013 17:41:20 UTC