- From: Niklas Lindström <lindstream@gmail.com>
- Date: Wed, 3 Jul 2013 21:47:14 +0200
- To: David Booth <david@dbooth.org>
- Cc: Robert Sanderson <azaroth42@gmail.com>, Pat Hayes <phayes@ihmc.us>, Linked JSON <public-linked-json@w3.org>, RDF WG <public-rdf-wg@w3.org>, public-openannotation <public-openannotation@w3.org>
- Message-ID: <CADjV5jf2o9ZSKPHHHRqNVGYU0+nJ0-Ri5kZhnToHj=t4Yiig5g@mail.gmail.com>
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:15 UTC