- From: Pat Hayes <phayes@ihmc.us>
- Date: Mon, 8 Jul 2013 23:46:14 -0500
- To: Robert Sanderson <azaroth42@gmail.com>
- Cc: David Booth <david@dbooth.org>, Niklas Lindström <lindstream@gmail.com>, Linked JSON <public-linked-json@w3.org>, RDF WG <public-rdf-wg@w3.org>, public-openannotation <public-openannotation@w3.org>
On Jul 8, 2013, at 1:01 PM, Robert Sanderson wrote: > Dear all, > > Clearly a contentious issue and one that could be avoided (if not necessarily solved) by adding a different predicate. I agree that creating another "sameAs" is not a viable path forwards, but perhaps something specific to lists would be possible? > > Something like: > > rdf:listHead -- The object, which must be a blank node with rdf:type rdf:List, is the first entry in a list associated with the subject resource. I guess I don't follow this. If the object is of type LIst, and it is the first item in a list, then you have a list of lists. Which is legal, but I don't see how it helps with the problem we have here. And what does "associated with" mean? Pat > > Which does not express equivalence or uniqueness of identity, but lets us have a nicely cross-ontology solution to the current issues. > > Many thanks for your continued engagement, and I hope that we can resolve the matter in a pragmatic and simple way that doesn't fall foul of existing implementations. > > Rob > > On Wed, Jul 3, 2013 at 10:37 PM, Pat Hayes <phayes@ihmc.us> wrote: > > On Jul 3, 2013, at 11:03 PM, David Booth wrote: > > > On 07/03/2013 11:05 PM, Pat Hayes wrote: > >> > >> 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 "=". > > > > But in this case they really don't need the semantics to be the same as owl:sameAs semantics, even if they did describe it that way. All they really need is to link the two nodes in a recognizable way. > > I hear what you are saying, but I think you will find that the actual *semantics* - the truth conditions on your json:link predicate - will have to be that it is true when its subject is the same as its object, ie it means s=o, just like owl:sameAs does. And given that *semantics*, the substitution of one side for the other will in fact be a *valid entailment*. > > Of course, you can say that for other, non-semantic, reasons you want to disallow such a substitution, which is fine: but you could also say this about this usage of owl:sameAs. There might well be pragmatic reasons for using a different property name (easier to recognize and check, avoids confusing OWL reasoners,. etc.), but my point is only that these are indeed syntactic/pragmatic reasons, not semantic. Just to keep the discussion clear, please don't say that json:link is described as equality but is not really equality, or some such nonsense. > > Pat > > > > > > David > > > >> 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 > >> > >> > >> > >> > >> > >> > >> > >> > > > > ------------------------------------------------------------ > 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 Tuesday, 9 July 2013 04:46:44 UTC