Re: JSON-LD Telecon Minutes for 2013-07-02

On Jul 2, 2013, at 12:40 PM, Manu Sporny wrote:

> 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.

If I understand this correctly, this can be done in RDF already. For example, the list [ x:a, x:b, 27 ] identified by the URI ex:thisList and possessing the property x:prop with value x:value is described by this RDF:

ex:thisList rdf:type rdf:List .
ex:thisList rdf:first x:a .
ex:thisLIst rdf:rest _:1 .
_:1 rdf:first x:b .
_:1 rdf:rest _:2 .
_:2 rdf:first "27"^^xsd:number .
_:2 rdf:rest rdf:nil .
ex:thisLIst x:prop x:value .

Pat

> 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/
> 
> 
> 

------------------------------------------------------------
IHMC                                     (850)434 8903 or (650)494 3973   
40 South Alcaniz St.           (850)202 4416   office
Pensacola                            (850)202 4440   fax
FL 32502                              (850)291 0667   mobile
phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes

Received on Wednesday, 3 July 2013 04:07:47 UTC