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

On 07/03/2013 10:46 PM, Pat Hayes wrote:
> q2 On Jul 3, 2013, at 1:40 PM, David Booth 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>
>
> Well, that is a *logically valid* consequence on the RDF as far as
> the RDF (plus in this case a bit of OWL) semantics is concerned. It
> is also logically valid to replace the URI by the blank node
> throughout, for that matter, or to do all kinds of other things to
> the RDF, such as just omitting half of the triples that describe the
> list in question. But (as the RDF 1.1 semantics document is at pains
> to point out), just because it is logically valid does not mean that
> it is required to be done or even that it is, in all cases, permitted
> to be done. Semantic extensions of RDF can impose syntactic
> conditions which require RDF graphs to be treated in special ways,
> and flag errors if they find violations of these syntactic
> conditions. OWL itself (well, OWL-DL) imposes all kinds of such
> conditions on its RDF encodings, for example.
>
>> , 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.
>
> And you can do this simply by requiring that your particular dialect
> of RDF requires it to not be eliminated. Use RFC 2119 language.

That does *not* sound like a good strategy, because that would prevent 
them from using standard tools, such as standard tools that add OWL 
entailments and standard leanifier tools, in order to avoid damaging 
their graphs.

>
>> 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.
>
> It is always the case that some RDF software can ruin almost any
> extension of RDF, while still being inferentially valid according to
> the pure RDF graph semantics. For example, it can legally, as far as
> basic RDF entailment is concerned, omit parts of any list. If I give
> you a complete description of a three-element list and you erase the
> part of it that describes the second element (as I did inadvertantly
> in my last email) then you have not done anything RDF-invalid; your
> partial description is still entailed by the complete description.
> But of course you have now screwed up any software which is expecting
> a complete list description. There is no way to *guarantee* that
> almost any use of RDF over and above a simple conjunction of
> triple-facts is going to be preserved by all semantically correct RDF
> operations. If you want to impose extra requirements, then publish
> them and explain to builders of engines how to preserve them and what
> kinds of errors to post when they find that things are not right
> according to your published standards.
>
> A 'good" RDF engine will not make gratuitous changes to RDF graphs
> (such as using a sameAs to "simplify" a graph, or erasing pieces of a
> list) without having a very good reason to do so, and will certainly
> not mess around with RDF and re-publish it without warning. We have
> not gone into RFC 2119 language about such matters because the RDF
> standard tries as far as possible to allow almost anything to be done
> with RDF, preciesly to allow extensions built on top of RDF to impose
> their own conditions.
>
>>
>> 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:
>
> This is *entailed*, yes. But so are many other things. (The empty
> graph is also entailed by this graph, for example.) That is not to
> say that this is a correct operation to apply as a modification to
> the graph.
>
>>
>> ... _: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
>> ... ).
>
> All you have shown is that a JSON-LD-correct RDF graph (if I may coin
> the term) may OWL-entail a graph which is not JSON-LD-correct.  Which
> is true but (1) unremarkable and (2) almost inevitable. The same
> point will be true no matter what form of list encoding you adopt:
> there will be an RDF-valid consequence of it that breaks your
> encodings. Thats just the way RDF is, loose and let-it-all-hang-out.
> Get used to it :-)

With all due respect, that seems quite misleading.  First of all, that 
is *not* all I have shown.  I have shown that if you put that graph 
through a *standard* module that adds OWL entailments, and then a 
*standard* module that leanifies the graph, you end up damaging the 
graph in a real, practical sense.  That is completely different from 
making the rather obvious point that a graph may be damaged if you 
discard half of the triples.

They need advice that is practical and useful in the context of standard 
tools.  In my experience it is *quite* possible to come up with a design 
that does not break when used with standard tools, but there are 
"gotchas" that need to be avoided, and it looks to me like this is one 
of them -- not a terribly serious one, but still one that is better to 
avoid, IMO.

David

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

Received on Thursday, 4 July 2013 04:02:58 UTC