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

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:48:14 UTC