- From: Robert Sanderson <azaroth42@gmail.com>
- Date: Wed, 3 Jul 2013 13:55:20 -0600
- To: Niklas Lindström <lindstream@gmail.com>
- Cc: David Booth <david@dbooth.org>, 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: <CABevsUEv-fsYDefZLbU=3bjc4kY1cv7Xri+DaVDBHFzz505+Aw@mail.gmail.com>
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? 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<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:55:50 UTC