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