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

On Jul 3, 2013, at 11:03 PM, David Booth wrote:

> On 07/03/2013 11:05 PM, Pat Hayes wrote:
>> 
>> On Jul 3, 2013, at 2:55 PM, Robert Sanderson wrote:
>> 
>>> 
>>> 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?
>> 
>> You could do that, and it might be operationally a smart thing to do
>> (see below). But David's worry will still apply to it. GIven what you
>> want it to mean, its actual *semantics* are going to be the same as
>> that of owl:sameAs, viz. that it means "=".
> 
> But in this case they really don't need the semantics to be the same as owl:sameAs semantics, even if they did describe it that way.  All they really need is to link the two nodes in a recognizable way.

I hear what you are saying, but I think you will find that the actual *semantics* - the truth conditions on your json:link predicate - will have to be that it is true when its subject is the same as its object, ie it means s=o, just like owl:sameAs does. And given that *semantics*, the substitution of one side for the other will in fact be a *valid entailment*. 

Of course, you can say that for other, non-semantic, reasons you want to disallow such a substitution, which is fine: but you could also say this about this usage of owl:sameAs. There might well be pragmatic reasons for using a different property name (easier to recognize and check, avoids confusing OWL reasoners,. etc.), but my point is only that these are indeed syntactic/pragmatic reasons, not semantic. Just to keep the discussion clear, please don't say that json:link is described as equality but is not really equality, or some such nonsense. 

Pat


> 
> David
> 
>> And given that semantics,
>> it will in fact be logically valid to substitute its subject term for
>> its object term. You can of course say that you don't want to allow
>> this, but it will be *semantically* valid as a logical entailment.
>> And you can *say* that you don't want the owl:SameAs substitutions to
>> be performed on lists. On the other hand, this "saying" might have
>> more bite, as it were, if you say it about a term that you own and
>> whose meaning is defined in your documents (that its root IRI will
>> link back to, in the great emerging LD tradition :-)
>> 
>> Pat
>> 
>> PS. BTW, don't ask the RDF WG to add some kind of rdf:sameAs to RDF.
>> They won't do it. The established usage in the RDF world is to use
>> owl:sameAs.
>> 
>>> 
>>> 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
>>> 
>>> 
> 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 (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/
>>>>>> 
>>>>>> 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).
>>> 
>>> 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 [[ 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.
>>> 
>>> 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
>>> 
>>>>>> 
>>>> 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 <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
>>>>>> 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
>>> <http://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
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>> 
>> ------------------------------------------------------------ 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 Thursday, 4 July 2013 04:38:01 UTC