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

On Jul 2, 2013, at 11:38 PM, David Booth wrote:

> On 07/03/2013 12:07 AM, Pat Hayes wrote:
>> 
>> 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 .
> 
> If I have understood the issue properly, the reason
> for raising this issue in the RDF working group is that this is not
> necessarily an advisable usage pattern for the RDF list vocabulary, because such a list cannot be serialized using Turtle's list syntax: (x:a x:b 27).

Others will have to speak to the Turtle syntax issue, but there is nothing inadvisable or improper about this construction. It uses the first/rest/nil pattern quite consistently (unlike the "anti-social" or "ill-formed" possibilities to which you refer below, about which the RDF 2004 specifications say "Semantic extensions MAY place extra syntactic well-formedness restrictions on the use of this vocabulary in order to rule out such graphs.") 

Pat


>  It falls into a  similar category as other uncommon uses of the RDF List vocabulary:
> http://www.w3.org/TR/rdf-schema/#ch_collectionvocab
> [[
> Note: RDFS does not require that there be only one first element of a list-like structure, or even that a list-like structure have a first element.
> ]]
> 
> While not prohibited by RDF, such uncommon uses of the RDF list vocabulary are certainly seen by some as being somewhat anti-social. Thus, the question is whether such uses should be *encouraged*.
> 
> David
> 
>> 
>> 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
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
> 

------------------------------------------------------------
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 06:00:06 UTC