- From: Pat Hayes <phayes@ihmc.us>
- Date: Wed, 3 Jul 2013 21:46:09 -0500
- To: David Booth <david@dbooth.org>
- Cc: Robert Sanderson <azaroth42@gmail.com>, Linked JSON <public-linked-json@w3.org>, RDF WG <public-rdf-wg@w3.org>, public-openannotation <public-openannotation@w3.org>
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. > 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 :-) 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 02:46:42 UTC