- From: Pat Hayes <phayes@ihmc.us>
- Date: Wed, 3 Jul 2013 22:05:15 -0500
- To: Robert Sanderson <azaroth42@gmail.com>
- Cc: Niklas Lindström <lindstream@gmail.com>, David Booth <david@dbooth.org>, Linked JSON <public-linked-json@w3.org>, RDF WG <public-rdf-wg@w3.org>, public-openannotation <public-openannotation@w3.org>
On Jul 3, 2013, at 2:55 PM, Robert Sanderson wrote: > > I would be very interested to hear Pat's take on the matter, but this does appear to be a valid concern with the reuse of owl:sameAs. > It seems that we're back to minting a new predicate to link the resource and the head node of the list? You could do that, and it might be operationally a smart thing to do (see below). But David's worry will still apply to it. GIven what you want it to mean, its actual *semantics* are going to be the same as that of owl:sameAs, viz. that it means "=". And given that semantics, it will in fact be logically valid to substitute its subject term for its object term. You can of course say that you don't want to allow this, but it will be *semantically* valid as a logical entailment. And you can *say* that you don't want the owl:SameAs substitutions to be performed on lists. On the other hand, this "saying" might have more bite, as it were, if you say it about a term that you own and whose meaning is defined in your documents (that its root IRI will link back to, in the great emerging LD tradition :-) Pat PS. BTW, don't ask the RDF WG to add some kind of rdf:sameAs to RDF. They won't do it. The established usage in the RDF world is to use owl:sameAs. > > Rob > > > On Wed, Jul 3, 2013 at 1:47 PM, Niklas Lindström <lindstream@gmail.com> wrote: > Thanks David, > > This worry was fleeting in the back of my mind as well, but I didn't really express it. > > It is also part of why I've been reluctant to proceed with the otherwise fairly low-hanging fruit of extending JSON-LD to support identifying and making statements about the front of an RDF list (by simply allowing '@id' and other terms in an object representing a literal list – i.e. an object using the '@list' key). > > (.. Not to mention that this would take us closer to asking why we can't do that for literals as well.. And then eventually discuss equating '@value' and 'rdf:value'.. Not that I am theoretically against such an evolution of RDF (that could solve the troublesome "literals as subjects" debate, render SKOS-XL obsolete, and even improve text search in SPARQL). But that would be nothing short of a RDF 2.0 endeavour. Which is way beyond this..) > > Cheers, > Niklas > > > > On Wed, Jul 3, 2013 at 8:40 PM, David Booth <david@dbooth.org> wrote: > Hi Rob, > > The owl:sameAs solution does have the right semantics, and it has the benefit of using a standard term. But I'm afraid there may be a downside as well, and I'm copying Pat to get his take on it. Normally when you have: > > <http://example/foo> owl:sameAs _:b1 . > > in a graph, the blank node can be completely eliminated from the graph and replaced by <http://example/foo>, because the semantics of a blank node merely indicates the *existence* of a resource, but the owl:sameAs assertion gives a concrete identity <http://example/foo> to that resource. But in your case, you want to *avoid* having that blank node eliminated. Thus, there could be some risk that smart software that attempts to eliminate unnecessary nodes and assertions (such as by making the graph "lean") > https://dvcs.w3.org/hg/rdf/raw-file/default/rdf-mt/index.html#dfn-lean > may eliminate the blank node triple that the Turtle serializer would need for serializing back to the original list syntax. > > In other words, if the original graph said: > > ... > _:b1 a rdf:List . > _:b1 rdf:first :s1 . > ... > > and you used owl:sameAs as above, then by owl:sameAs entailment we would have: > > ... > _:b1 a rdf:List . > <http://example/foo> a rdf:List . > _:b1 rdf:first :s1 . > <http://example/foo> rdf:first :s1 . > ... > > and if that were made lean then it would become: > > ... > <http://example/foo> a rdf:List . > <http://example/foo> rdf:first :s1 . > ... > > which would not serialize back to the original Turtle list ( :s1 ... ). > > David > > > On 07/03/2013 11:15 AM, Robert Sanderson wrote: > > Dear all, > > TL;DR version: I think that owl:sameAs is a great solution for the > predicate. > > Thank you for the discussion! > > The primary use case for lists with identity (and other properties, > potentially) in Open Annotation is to have an ordered workflow for > selecting the correct part of a document. For example, EPub documents > are just zip files with HTML and other resources packed inside them, so > it would be beneficial to reuse the methods for selecting the correct > segment of a resource on the web with the resources inside the EPub, but > first the file within the zip must be selected. > > Thus we would want: > > <target1> a oa:SpecificResource ; > oa:hasSelector <list1> ; > oa:hasSource <epub1> . > > <list1> a oa:List, rdf:List ; > rdf:isList (<FileSelector>, <TextSelector>) . > // Or something similar here > > <FileSelector> a idpf:EpubFileSelector ; > rdf:value "/chapter1.html" . > > <TextSelector> a oa:TextQuoteSelector ; > oa:prefix "bit before the segment" > oa:exact "The text of the annotated segment" > oa:suffix "bit after the segment" > > > The relevant part of the specification is: > http://www.openannotation.org/spec/core/multiplicity.html#List > (and you'll see the long red editor's note!) > > I think that Pat's suggestion of owl:sameAs is very appropriate. It > works in the different syntaxes and has the semantics that the resources > are the same -- in the case above the blank node that has first of > <FileSelector> and the resource <list1>. > > The other options discussed were rdf:value, which is extremely fuzzy and > in JSON-LD context you couldn't assert that it always had a list as its > object if it was also used with a literal. In which case it would result > in multiple rdf:value predicates, each with one of the list items as > object. That led to discussing a new predicate, such as listItems, > listValue, isList, or similar. This would have the implication that the > blank node and the main identified resource were different resources, as > compared to the proposal of owl:sameAs which would mean they were the > same resource. > > Rob > > > > > > > On Wed, Jul 3, 2013 at 12:30 AM, Pat Hayes <phayes@ihmc.us > <mailto:phayes@ihmc.us>> wrote: > > > On Jul 2, 2013, at 11:38 PM, David Booth wrote: > > > On 07/03/2013 12:07 AM, Pat Hayes wrote: > >> > >> On Jul 2, 2013, at 12:40 PM, Manu Sporny wrote: > >> > >>> Thanks to Niklas for scribing. The minutes from this week's telecon > >>> are now available. > >>> > >>> http://json-ld.org/minutes/2013-07-02/ > >>> > >>> Full text of the discussion follows including a link to the audio > >>> transcript: > >>> > >>> ------------------------------------------------------------------- > >>> > >>> > > JSON-LD Community Group Telecon Minutes for 2013-07-02 > >>> > >>> Agenda: > >>> > http://lists.w3.org/Archives/Public/public-linked-json/2013Jul/0000.html > >>> > >>> > > Topics: > >>> 1. Assigning Properties to Lists 2. GSoC update 3. JSON-LD / RDF > >>> Alignment 4. Lists in the JSON and RDF data models 5. Default > >>> interpretation of JSON arrays Resolutions: 1. Create an issue in > >>> the RDF WG to formalize a way to express lists that need to be > >>> identified with a URL and annotated using properties. > >> > >> If I understand this correctly, this can be done in RDF already. For > >> example, the list [ x:a, x:b, 27 ] identified by the URI ex:thisList > >> and possessing the property x:prop with value x:value is > described by > >> this RDF: > >> > >> ex:thisList rdf:type rdf:List . ex:thisList rdf:first x:a . > >> ex:thisLIst rdf:rest _:1 . _:1 rdf:first x:b . _:1 rdf:rest _:2 > . _:2 > >> rdf:first "27"^^xsd:number . _:2 rdf:rest rdf:nil . ex:thisLIst > >> x:prop x:value . > > > > If I have understood the issue properly, the reason > > for raising this issue in the RDF working group is that this is not > > necessarily an advisable usage pattern for the RDF list > vocabulary, because such a list cannot be serialized using Turtle's > list syntax: (x:a x:b 27). > > Yes, you are right, and I confess I had never noticed this > limitation of Turtle previously. OK, let me change the RDF to the > following, keeping the list bnodes but using owl:sameAs. (You can of > course use some other property indicating equality if y'all prefer.): > > ex:thisLIst rdf:type rdf:List . > ex:thisLIst x:prop x:value . > ex:thisList owl:sameAs _:3 . > _:3 rdf:first x:a . > _:3 rdf:rest _:1 . > _:1 rdf:rest _:2 . > _:2 rdf:first "27"^^xsd:number . > _:2 rdf:rest rdf:nil . > > Or, in Turtle: > > ex:thisList rdf:type rdf:List ; > x:prop x:value ; > owl:sameAs (x:a , x:b, 27 ) . > > and you could probably omit the first triple, or even introduce your > own category of JSON-lists and say it is one of those, instead, if > that would help with triggering appropriate translations into other > formats (or to distinguish these from eg RDF lists used to encode > OWL syntax.) > > > It falls into a similar category as other uncommon uses of the > RDF List vocabulary:... > > ...no, it doesn't. See remark below. > > Pat > > > other uncommon uses of the RDF List vocabulary: > > http://www.w3.org/TR/rdf-schema/#ch_collectionvocab > > [[ > > Note: RDFS does not require that there be only one first element > of a list-like structure, or even that a list-like structure have a > first element. > > ]] > > > > While not prohibited by RDF, such uncommon uses of the RDF list > vocabulary are certainly seen by some as being somewhat anti-social. > Thus, the question is whether such uses should be *encouraged*. > > > > David > > > >> > >> Pat > >> > >>> Chair: Manu Sporny Scribe: Niklas Lindström Present: Niklas > >>> Lindström, Robert Sanderson, Markus Lanthaler, Manu Sporny, David > >>> Booth, David I. Lehn, Vikash Agrawal Audio: > >>> http://json-ld.org/minutes/2013-07-02/audio.ogg > >>> > >>> Niklas Lindström is scribing. > >>> > >>> Topic: Assigning Properties to Lists > >>> > >>> Markus Lanthaler: https://github.com/json-ld/json-ld.org/issues/75 > >>> Robert Sanderson: we'd very much like to give rdf:Lists identity, > >>> so that they can be referenced from multiple graphs. Also to > >>> describe them with other properties ... in openannotation, we need > >>> lists to define a selector which determines which part is > >>> annotated ... for instance, which piece of a text is annotated, > >>> with "before" and "after" also recorded (most clients work like > >>> that) ... Futhermore, IDPF has agreed to use openannotation for > >>> all EPub books ... EPubs, being zip files with a bunch of files ... > >>> To define a selector here (take the EPub, select a file, then a > >>> part in there) ... So we don't want to reproduce every single > >>> selector mechanism. Thus, an ordered list of two selectors would > >>> be neeeded. ... We thus need to identify lists, so that we can > >>> reuse these selectors in multiple statements. ... I.e. a person > >>> wants to disagree with a specific annotation, or place being > >>> annotated. ... Furthermore, we have the order of multiple targets, > >>> e..g. "the first passage on page three, is derived from the second > >>> passage on page five" ... Not as essential, since it's not really > >>> machine actionable ... Another project using lists is Shared > >>> Canvas ... We'd very much like to use JSON-LD there too, for > >>> selecting pages, using a list of pages and so forth ... For this, > >>> we took the "list items" approach; the list doesn't need to be > >>> referenced directly. Markus Lanthaler: robert, do you have the link > >>> of an example at hand? ... But it might be nice to have this > >>> standardized, so people don't reinvent list items all the time. ... > >>> at the mailing list and also the OA community meeting in Europe, we > >>> agreed that we don't want to change the model to accomodate > >>> different syntaxes ... We want to recommend JSON-LD Manu Sporny: > >>> what's the timeline for these needs / when would the WG close > >>> Robert Sanderson: at the moment, the CG is in an implementation > >>> phase. We need to dicuss with Ivan, but we hope to move from CG to > >>> WG next year Manu Sporny: we're very close to CR in JSON-LD. If > >>> we'd add his feature in, it would put us back for many months. > >>> Could we add this for JSON-LD 1.1? ... If we think we can put the > >>> feature in, I think we can easily convince implementers to add it. > >>> If we add it to the test suite, other implementers would add it. > >>> ... So for practical purposes, we aim for it to be added within a > >>> year or so. Robert Sanderson: Yes, that approach could work for > >>> us. Given that your'e much further ahead. It's not our prefered > >>> option, since for implementations, it might be unpredictable. ... > >>> Also, changing this for OA now is much easier than when in a WG ... > >>> I don't believe anyone has implemented it yet, but IDPF needs this > >>> to be implementable Manu Sporny: so we may put it in jSON-LD 1.1 > >>> Niklas Lindström: First thing, as far as I know, Turtle doesn't > >>> support this syntax either. Given that you have a shorthand in > >>> Turtle.... actually, none of the formats in RDF/XML and Turtle > >>> support this sort of list syntax. [scribe assist by Manu Sporny] > >>> Markus Lanthaler: niklasl, AFAICT they currently set rdf:rest to a > >>> Turtle list Niklas Lindström: Have you discussed that as well? Am > >>> I missing something? [scribe assist by Manu Sporny] Robert > >>> Sanderson: No, I don't think you missed anything. [scribe assist > >>> by Manu Sporny] Robert Sanderson: The identity is easier in > >>> RDF/XML - you have the property for the URI. [scribe assist by Manu > >>> Sporny] Robert Sanderson: We did consider the other > >>> serializations, it's not a ubiquitous feature, but it would be nice > >>> to have in JSON-LD. [scribe assist by Manu Sporny] Niklas > >>> Lindström: Right, the main argument when we had the issue, even > >>> though it's in the Primer that says there is nothing preventing > >>> lists from being described, multiple start properties, etc. None of > >>> the core syntaxes allow it, it's not intended to be used like that. > >>> [scribe assist by Manu Sporny] Niklas Lindström: They're supposed > >>> to be used as syntactic constructs.... model-wise, they're not > >>> really a part of RDF. > > That is not correct. Collections were intended to be an integral > part of RDF. They were used by OWL as a syntactic device for > encoding OWL syntax in RDF, making them unavailable inside OWL, but > that is an OWL/RDF issue. (IMO, with hindsight, this was a serious > mistake in designing the OWL/RDF layering. But I was there at the > time and didn't see the danger myself, so mia culpa.) > > >>> [scribe assist by Manu Sporny] Niklas > >>> Lindström: If this is supported in JSON-LD, it would be a lot > >>> easier to deviate from the recommended usage pattern.... also > >>> making it harder for a future RDF spec, who wants to add lists as a > >>> native part of the model [scribe assist by Manu Sporny] Niklas > >>> Lindström: You can still use rdf:first / rdf:next explicitly > >>> today. [scribe assist by Manu Sporny] Robert Sanderson: I agree. > >>> The notion of order in a graph is always problematic. Not the > >>> common method to have a resource that is a list and has identity. > >>> [scribe assist by Manu Sporny] Robert Sanderson: Maybe RDF > >>> COncepts 1.1 should discuss it. [scribe assist by Manu Sporny] > >>> David Booth: Yeah, RDF WG should consider this. I agree with > >>> Niklas. It doesn't fit w/ the usual list pattern. Important to > >>> consider implications. [scribe assist by Manu Sporny] ... Here's an > >>> example: > >>> http://www.openannotation.org/spec/core/multiplicity.html#List > >>> Robert Sanderson: That's it exactly, thanks Niklas1 Manu Sporny: > >>> any other thoughs on this? Markus Lanthaler: it would make it hard > >>> to expect compaction to behave as predicted ... also, compaction > >>> might be more complex Manu Sporny: Yes. We wanted to stay away > >>> from it since it might be a mine field in general. ... that said, > >>> there might be a case for this. Niklas Lindström: Agree with > >>> Manu's point - there might be something new that's interesting > >>> here. I don't think we should do it w/o discussing implications. > >>> Algorithmic complexity for JSON-LD API and implementations. It > >>> might be almost as problematic as bnodes as predicates. It's > >>> possible to do this in raw RDF. It seems highly obvious that you > >>> can add ID in other properties. On the other hands you... [scribe > >>> assist by Manu Sporny] Manu Sporny: ...can do it w/ literals. > >>> Niklas Lindström: This borders on the syntactical collapse. > >>> [scribe assist by Manu Sporny] Markus Lanthaler: syntactically > >>> having a property carrying the actual list is nearly > >>> indistinguishable as the requested form (using "@list" as key) > >>> Robert Sanderson: I agree. The easisest solution for everyone > >>> would be to have a "listItem" as a property. ... and for the RDF > >>> WG, it might be good to define a dedicated predicate for it. > >>> rdf:value is explicitly fuzzy, so you can't always expect a list. > >>> David Booth: Robert, would it be feasible to just wrap the list in > >>> another object, and attach the additional info to the wrapper > >>> object? (I apologize that I have not fully grokked the problem, so > >>> this suggestion may not be helpful.) ... It would be easier to sell > >>> changing the model if there was another predicate for this. Manu > >>> Sporny: so a specific vocabulary for lists would be beneficial in > >>> general, working in all syntaxes ... would that adress this issue? > >>> If we quickly create a list vocabulary? Robert Sanderson: I think > >>> so. Not preferable duing the discussions we had, but the syntactic > >>> arguments may sway this position. ... A single, interoperable > >>> solution is preferable. Manu Sporny: anyone objects to open issue > >>> 75, to continue this dicussion? Niklas Lindström: I think we > >>> should try to have this as an RDF issue - it really would not come > >>> up if lists were core to the RDF model. It's a sore spot in RDF > >>> Concepts. I think we should push it over to the RDF WG immediately. > >>> It's arbitrary if we or OA try to push something forward, it won't > >>> solve the real problem.... not in rdf schema vocab. [scribe assist > >>> by Manu Sporny] Robert Sanderson: +1 to Niklas > >>> > >>> PROPOSAL: Create an issue in the RDF WG to formalize a way to > >>> express lists that need to be identified with a URL and annotated > >>> using properties. > >>> > >>> Manu Sporny: +1 David Booth: +1 Robert Sanderson: +1 Niklas > >>> Lindström: +1 could be someything like rdf:listValue David I. Lehn: > >>> +1 Markus Lanthaler: +1 > >>> > >>> RESOLUTION: Create an issue in the RDF WG to formalize a way to > >>> express lists that need to be identified with a URL and annotated > >>> using properties. > >>> > >>> Topic: GSoC update > >>> > >>> Vikash Agrawal: what's broken in the playground? Manu Sporny: a > >>> bit weird ui paradigm when clicking on expanded form; headings for > >>> JSON-LD Context stay, but the input box disappears. Markus > >>> Lanthaler: http://www.markus-lanthaler.com/jsonld/playground/ > >>> Markus Lanthaler: the headers stay but the inputs disappear. > >>> Previously headers were toggled off if input areas weren't > >>> applicable Manu Sporny: play around a bit. I think the old way is > >>> better. There may be something even better, but right now, the > >>> problem is that something not used is still shown. Vikash Agrawal: > >>> this is bug 50 ... by this week, this should be done. Next week is > >>> a creator app. Markus Lanthaler: could we discuss these things on > >>> the mailing list or the issue tracker? Manu Sporny: email danbri > >>> and gregg regarding a schema.org <http://schema.org> JSON-LD > context Markus Lanthaler: > >>> vikash, here's Sandro's schema.org <http://schema.org> context: > > >>> http://www.w3.org/People/Sandro/schema-org-context.jsonld Markus > >>> Lanthaler: for the creator app, have a look at: > >>> http://schema-creator.org/ > >>> > >>> Topic: JSON-LD / RDF Alignment > >>> > >>> Manu Sporny: > >>> http://lists.w3.org/Archives/Public/public-rdf-wg/2013Jun/0233.html > >>> > >>> > > Manu Sporny: I went into the spec and tried to integrate what we > >>> have consensus on. ... see the email link above for a list of > >>> things. ... everything should be there except for skolemization > >>> David Booth: I just found it, but I think it looks great (just > >>> some minor things) Manu Sporny: would it adress the LC comment? > >>> David Booth: It might. It's in the right direction. Manu Sporny: > >>> > http://json-ld.org/spec/ED/json-ld/20130630/diff-20130411.html#data-model > >>> > >>> > > Manu Sporny: next, Peter's changes. Appendix A was changed to > >>> flat out say that JSON-LD uses an extended RDF model. ... we just > >>> say "Data Model", and that it's an extension of the RDF data > >>> model. Markus Lanthaler: > >>> http://lists.w3.org/Archives/Public/public-rdf-wg/2013Jul/0010.html > >>> > >>> > > ... we need to have a resonse from Peter on this. > >>> David Booth: I'd expect it to be, to the extent that I can channel > >>> Peter. David Booth: Every node is an IRI , a blank node , a > >>> JSON-LD value , or a list . David Booth: restricting the literal > >>> space to JSON-LD values is a restriction rather than an extension > >>> to the RDF model. Robert Sanderson: Sorry, have to attend another > >>> call now, though would like to have stayed for the rest of the > >>> conversation. Thanks everyone for the discussion re lists. ... and > >>> I don't think that lists need to be mentioned there; they are just > >>> sugar. Markus Lanthaler: "A JSON-LD value is a string, a number, > >>> true or false, a typed value, or a language-tagged string." Markus > >>> Lanthaler: thanks for joining robert Manu Sporny: on top, we > >>> extension the value space to json true and false, numbers and > >>> strings. David Booth: A JSON-LD value is a string , a number , true > >>> or false , a typed value , or a language-tagged string . David > >>> Booth: it wasn't clear that those lined up with the corresponding > >>> RDF value space. Manu and David agree that the JSON number value > >>> space is more general. Manu Sporny: different lexical spaces for > >>> booleans in xsd and json > >>> > >>> Topic: Lists in the JSON and RDF data models > >>> > >>> David Booth: What about lists, aren't they the same as expressed > >>> in RDF? Manu Sporny: not convinced that they are.. ... we need to > >>> translate it to something in the data model. In RDF, it translates > >>> to the list properties. There is nothing in RDF concepts to point > >>> to. ... many just assumes that it's basically part of the data > >>> model, but it's formally not David Booth: why not point to rdf > >>> schema? Manu Sporny: not part of the rdf data model. Niklas > >>> Lindström: Yeah, just a comment. Could we correlate this RDF > >>> Concepts problem w/ the suggestion wrt. list values. [scribe assist > >>> by Manu Sporny] David Booth: RDF lists: David Booth: > >>> http://www.w3.org/TR/rdf-schema/#ch_list Niklas Lindström: > >>> Clearly, lists are under-specified. [scribe assist by Manu Sporny] > >>> Niklas Lindström: Maybe we should expand RDF Concepts that is > >>> present in the 2004 Primer and the Syntax that I scanned > >>> previously. [scribe assist by Manu Sporny] Manu Sporny: but does > >>> rdf schema extend the rdf data model? David Booth: no, just a > >>> convention which is using the rdf data model Markus Lanthaler: > >>> but's still just a vocabulary. In JSON-LD, we use [a keyword and] > >>> an array ... it's like a node type [just as literals] Manu Sporny: > >>> the JSON-LD data model does not talk about rdf:first and rdf:rest > >>> David Booth: I don't think any test cases needs to be changed by > >>> the way this is described. So it's just a question of how this > >>> concept is being described. At present, it's described as a > >>> difference. Manu Sporny: True. We only change how you think about > >>> the data model. Manu Sporny: if we make an argument about the > >>> difference between native JSON literals and RDF literals, we need > >>> to explain the difference of expressing lists as well. David Booth: > >>> I don't see the benefit as a difference, from an RDF perspective. > >>> Niklas Lindström: I think I can answer re: benefit of having > >>> different model wrt. JSON lists and RDF lists. In JSON, there are > >>> arrays, those arrays represent repeated statements in RDF> [scribe > >>> assist by Manu Sporny] Niklas Lindström: RDF people understands > >>> that intuitively. We mention @set because people that don't > >>> understand RDF, but do understand mathematical sets.... ordered > >>> list is more popular than sets in programming. [scribe assist by > >>> Manu Sporny] Niklas Lindström: We need a way to explain lists in > >>> JSON-LD, in the same way that we explain sets, and other things. > >>> Not in a way that introduces rdf:first and rdf:next. [scribe assist > >>> by Manu Sporny] David Booth: Bottom line: I do not see a need to > >>> call out lists as being a difference from the RDF model, but I'm > >>> okay with it being mentioned, in part because I'd like to push RDF > >>> to have native lists. Markus Lanthaler: manu, did you see > >>> http://lists.w3.org/Archives/Public/public-rdf-wg/2013Jul/0010.html > >>> > >>> > > already? > >>> > >>> Topic: Default interpretation of JSON arrays > >>> > >>> David Booth: it seems strange to have @set (unordered) as the > >>> default ... in regular json, the default is ordered Markus > >>> Lanthaler: We discussed this quite a bit in the beginning, the > >>> rationale was that the RDF that was generated would be unmanageable > >>> - lots of blank nodes, lots of rdf:first/rdf:rest, you couldn't > >>> work w/ the RDF anymore. [scribe assist by Manu Sporny] Markus > >>> Lanthaler: we discussed it quite a bit in the beginning. The > >>> rationale we came up with is that the generated RDF would be very > >>> gruesome, using rdf lists for everything. ... hundreds of blank > >>> nodes for everything. Niklas Lindström: Yeah, I agree. That's the > >>> rationale. While it's true that arrays in JSON are ordered in their > >>> nature, in all the JSON-LD examples, they are commonly only sets. > >>> There is no real order. JSON-LD is intended to be used w/ RDF > >>> properties, there are only a handful of common RDF properties - > >>> author, contributorList, propertyChainAction, where the order is > >>> semantic, it means something. [scribe assist by Manu Sporny] Niklas > >>> Lindström: In every other case, it's just a bundle of things. I > >>> think that's the better case - explicitly say order doesn't mean > >>> anything. The same thinking has obscured lots of things wrt. XML. > >>> You can rely on the order of the elements, not sure if you should. > >>> It's better to say that "you can't rely on the order", unless > >>> someone says so explicitly. [scribe assist by Manu Sporny] David > >>> Booth: As a programmer, I'd use the exact opposite rationale. > >>> [scribe assist by Manu Sporny] David Booth: So if the default were > >>> changed to being ordered, then the examples would have to be > >>> changed to add @set? Markus Lanthaler: > >>> https://github.com/json-ld/json-ld.org/issues/12 Niklas Lindström: > >>> We discussed whether we should do it in the @context, we could > >>> define @set to be the default. [scribe assist by Manu Sporny] > >>> Niklas Lindström: I agree w/ David that as a programmer, you think > >>> like that. Unless you think otherwise. [scribe assist by Manu > >>> Sporny] David Booth: There is also minimal changes going from JSON > >>> to JSON-LD. [scribe assist by Manu Sporny] Niklas Lindström: > >>> Datasets on the Web, you never know if the order is intentional or > >>> not. It's better to assume that it's not ordered. [scribe assist by > >>> Manu Sporny] Markus Lanthaler: JSON-LD can already serialize the > >>> same data in so many ways already - remote contexts, you can't > >>> really interpret the data anymore by just looking at it. Maybe > >>> doing it in a processor flag, but not in the context. [scribe > >>> assist by Manu Sporny] Niklas Lindström: I'd like to be able to do > >>> this in the context. "@container": "@set" would be useful to me. > >>> [scribe assist by Manu Sporny] David Booth: Can we have a global > >>> way to indicate @set ? Niklas Lindström: Yeah, but I could wait > >>> for this feature. [scribe assist by Manu Sporny] David Booth: I'm > >>> worried about the element of surprise. It reverses the common > >>> expectation. Manu Sporny: It has not come up as a real issue from > >>> anywere though. Markus Lanthaler: Is there a use case for this? > >>> [scribe assist by Manu Sporny] Markus Lanthaler: In the majority > >>> of instances, the order is irrelevant David Booth: yes, quite > >>> possible Manu Sporny: a change could also backfire at this stage > >>> ... we could potentially have a JSON-LD 1.1, for e.g. this. David > >>> Booth: I think the best solution would be a simple global way to > >>> specify @set, and user get used to always doing that. Niklas > >>> Lindström: I think that it can't fly from my point of view - given > >>> that for every case where I've seen order having meaning, it's > >>> always been a very specific technical reason. Implicitly ordered > >>> things as properties on the object. In every specific scenario > >>> where order is used.... [scribe missed] [scribe assist by Manu > >>> Sporny] Niklas Lindström: check out schema.org > <http://schema.org>· only a handful > > >>> where the meaning is explicitly ordered: > >>> http://www.w3.org/People/Sandro/schema-org-context.jsonld Niklas > >>> Lindström: I might be open that it should be ordered, but not by > >>> default. [scribe assist by Manu Sporny] > >>> > >>> -- manu > >>> > >>> -- Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu > >>> Sporny) Founder/CEO - Digital Bazaar, Inc. blog: Meritora - Web > >>> payments commercial launch http://blog.meritora.com/launch/ > >>> > >>> > >>> > >> > >> ------------------------------------------------------------ IHMC > >> (850)434 8903 or (650)494 3973 40 South Alcaniz St. > >> (850)202 4416 office Pensacola (850)202 > >> 4440 fax FL 32502 (850)291 0667 > >> mobile phayesAT-SIGNihmc.us http://www.ihmc.us/users/phayes > >> > >> > >> > >> > >> > >> > >> > >> > >> > > > > ------------------------------------------------------------ > IHMC (850)434 8903 or (650)494 3973 > 40 South Alcaniz St. (850)202 4416 office > Pensacola (850)202 4440 fax > FL 32502 (850)291 0667 mobile > phayesAT-SIGNihmc.us http://www.ihmc.us/users/phayes > > > > > > > > > > ------------------------------------------------------------ IHMC (850)434 8903 or (650)494 3973 40 South Alcaniz St. (850)202 4416 office Pensacola (850)202 4440 fax FL 32502 (850)291 0667 mobile phayesAT-SIGNihmc.us http://www.ihmc.us/users/phayes
Received on Thursday, 4 July 2013 03:05:45 UTC