Re: JSON-LD Telecon Minutes for 2013-07-02

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.

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
>
>
>
>
>
>