W3C home > Mailing lists > Public > public-openannotation@w3.org > July 2013

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

From: Robert Sanderson <azaroth42@gmail.com>
Date: Wed, 3 Jul 2013 13:55:20 -0600
Message-ID: <CABevsUEv-fsYDefZLbU=3bjc4kY1cv7Xri+DaVDBHFzz505+Aw@mail.gmail.com>
To: Niklas Lindström <lindstream@gmail.com>
Cc: David Booth <david@dbooth.org>, Pat Hayes <phayes@ihmc.us>, Linked JSON <public-linked-json@w3.org>, RDF WG <public-rdf-wg@w3.org>, public-openannotation <public-openannotation@w3.org>
I would be very interested to hear Pat's take on the matter, but this does
appear to be a valid concern with the reuse of owl:sameAs.
It seems that we're back to minting a new predicate to link the resource
and the head node of the list?

Rob


On Wed, Jul 3, 2013 at 1:47 PM, Niklas Lindström <lindstream@gmail.com>wrote:

> Thanks David,
>
> This worry was fleeting in the back of my mind as well, but I didn't
> really express it.
>
> It is also part of why I've been reluctant to proceed with the otherwise
> fairly low-hanging fruit of extending JSON-LD to support identifying and
> making statements about the front of an RDF list (by simply allowing '@id'
> and other terms in an object representing a literal list – i.e. an object
> using the '@list' key).
>
> (.. Not to mention that this would take us closer to asking why we can't
> do that for literals as well.. And then eventually discuss equating
> '@value' and 'rdf:value'.. Not that I am theoretically against such an
> evolution of RDF (that could solve the troublesome "literals as subjects"
> debate, render SKOS-XL obsolete, and even improve text search in SPARQL).
> But that would be nothing short of a RDF 2.0 endeavour. Which is way beyond
> this..)
>
> Cheers,
> Niklas
>
>
>
> On Wed, Jul 3, 2013 at 8:40 PM, David Booth <david@dbooth.org> wrote:
>
>> Hi Rob,
>>
>> The owl:sameAs solution does have the right semantics, and it has the
>> benefit of using a standard term.   But I'm afraid there may be a downside
>> as well, and I'm copying Pat to get his take on it.  Normally when you have:
>>
>>   <http://example/foo> owl:sameAs _:b1 .
>>
>> in a graph, the blank node can be completely eliminated from the graph
>> and replaced by <http://example/foo>, because the semantics of a blank
>> node merely indicates the *existence* of a resource, but the owl:sameAs
>> assertion gives a concrete identity <http://example/foo> to that
>> resource.  But in your case, you want to *avoid* having that blank node
>> eliminated.  Thus, there could be some risk that smart software that
>> attempts to eliminate unnecessary nodes and assertions (such as by making
>> the graph "lean")
>> https://dvcs.w3.org/hg/rdf/**raw-file/default/rdf-mt/index.**
>> html#dfn-lean<https://dvcs.w3.org/hg/rdf/raw-file/default/rdf-mt/index.html#dfn-lean>
>> may eliminate the blank node triple that the Turtle serializer would need
>> for serializing back to the original list syntax.
>>
>> In other words, if the original graph said:
>>
>>   ...
>>   _:b1 a rdf:List .
>>   _:b1 rdf:first :s1 .
>>   ...
>>
>> and you used owl:sameAs as above, then by owl:sameAs entailment we would
>> have:
>>
>>   ...
>>   _:b1 a rdf:List .
>>   <http://example/foo> a rdf:List .
>>   _:b1 rdf:first :s1 .
>>   <http://example/foo> rdf:first :s1 .
>>   ...
>>
>> and if that were made lean then it would become:
>>
>>   ...
>>   <http://example/foo> a rdf:List .
>>   <http://example/foo> rdf:first :s1 .
>>   ...
>>
>> which would not serialize back to the original Turtle list ( :s1 ... ).
>>
>> David
>>
>>
>> On 07/03/2013 11:15 AM, Robert Sanderson wrote:
>>
>>>
>>> Dear all,
>>>
>>> TL;DR version:  I think that owl:sameAs is a great solution for the
>>> predicate.
>>>
>>> Thank you for the discussion!
>>>
>>> The primary use case for lists with identity (and other properties,
>>> potentially) in Open Annotation is to have an ordered workflow for
>>> selecting the correct part of a document. For example, EPub documents
>>> are just zip files with HTML and other resources packed inside them, so
>>> it would be beneficial to reuse the methods for selecting the correct
>>> segment of a resource on the web with the resources inside the EPub, but
>>> first the file within the zip must be selected.
>>>
>>> Thus we would want:
>>>
>>> <target1> a oa:SpecificResource ;
>>>    oa:hasSelector <list1> ;
>>>    oa:hasSource <epub1> .
>>>
>>> <list1> a oa:List, rdf:List ;
>>>    rdf:isList (<FileSelector>, <TextSelector>) .
>>> // Or something similar here
>>>
>>> <FileSelector> a idpf:EpubFileSelector ;
>>>    rdf:value "/chapter1.html" .
>>>
>>> <TextSelector> a oa:TextQuoteSelector ;
>>>    oa:prefix "bit before the segment"
>>>    oa:exact "The text of the annotated segment"
>>>    oa:suffix "bit after the segment"
>>>
>>>
>>> The relevant part of the specification is:
>>> http://www.openannotation.org/**spec/core/multiplicity.html#**List<http://www.openannotation.org/spec/core/multiplicity.html#List>
>>> (and you'll see the long red editor's note!)
>>>
>>> I think that Pat's suggestion of owl:sameAs is very appropriate. It
>>> works in the different syntaxes and has the semantics that the resources
>>> are the same -- in the case above the blank node that has first of
>>> <FileSelector> and the resource <list1>.
>>>
>>> The other options discussed were rdf:value, which is extremely fuzzy and
>>> in JSON-LD context you couldn't assert that it always had a list as its
>>> object if it was also used with a literal. In which case it would result
>>> in multiple rdf:value predicates, each with one of the list items as
>>> object. That led to discussing a new predicate, such as listItems,
>>> listValue, isList, or similar.  This would have the implication that the
>>> blank node and the main identified resource were different resources, as
>>> compared to the proposal of owl:sameAs which would mean they were the
>>> same resource.
>>>
>>> Rob
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Wed, Jul 3, 2013 at 12:30 AM, Pat Hayes <phayes@ihmc.us
>>> <mailto:phayes@ihmc.us>> wrote:
>>>
>>>
>>>     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/<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<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).
>>>
>>>     Yes, you are right, and I confess I had never noticed this
>>>     limitation of Turtle previously. OK, let me change the RDF to the
>>>     following, keeping the list bnodes but using owl:sameAs. (You can of
>>>     course use some other property indicating equality if y'all prefer.):
>>>
>>>     ex:thisLIst rdf:type rdf:List .
>>>     ex:thisLIst x:prop x:value .
>>>     ex:thisList owl:sameAs _:3 .
>>>     _:3 rdf:first x:a .
>>>     _:3 rdf:rest _:1 .
>>>     _:1 rdf:rest _:2 .
>>>     _:2 rdf:first "27"^^xsd:number .
>>>     _:2 rdf:rest rdf:nil .
>>>
>>>     Or, in Turtle:
>>>
>>>     ex:thisList rdf:type rdf:List ;
>>>            x:prop x:value ;
>>>            owl:sameAs (x:a , x:b, 27 ) .
>>>
>>>     and you could probably omit the first triple, or even introduce your
>>>     own category of JSON-lists and say it is one of those, instead, if
>>>     that would help with triggering appropriate translations into other
>>>     formats (or to distinguish these from eg RDF lists used to encode
>>>     OWL syntax.)
>>>
>>>      >  It falls into a  similar category as other uncommon uses of the
>>>     RDF List vocabulary:...
>>>
>>>     ...no, it doesn't. See remark below.
>>>
>>>     Pat
>>>
>>>      > other uncommon uses of the RDF List vocabulary:
>>>      > http://www.w3.org/TR/rdf-**schema/#ch_collectionvocab<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<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 <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.
>>>
>>>     That is not correct. Collections were intended to be an integral
>>>     part of RDF. They were used by OWL as a syntactic device for
>>>     encoding OWL syntax in RDF, making them unavailable inside OWL, but
>>>     that is an OWL/RDF issue. (IMO, with hindsight, this was a serious
>>>     mistake in designing the OWL/RDF layering. But I was there at the
>>>     time and didn't see the danger myself, so mia culpa.)
>>>
>>>      >>> [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 <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/<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 <http://schema.org> JSON-LD
>>>     context Markus Lanthaler:
>>>      >>> vikash, here's Sandro's schema.org <http://schema.org> context:
>>>
>>>      >>> http://www.w3.org/People/**Sandro/schema-org-context.**jsonld<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<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<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<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<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<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<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
>>>     <http://schema.org>· only a handful
>>>
>>>      >>> where the meaning is explicitly ordered:
>>>      >>> http://www.w3.org/People/**Sandro/schema-org-context.**jsonld<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/<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<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<http://www.ihmc.us/users/phayes>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>
Received on Wednesday, 3 July 2013 19:55:50 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 3 July 2013 19:55:50 UTC