Re: comments/questions on JSON-LD spec (but _not_ for the CG->WG transition!)

On Jun 17, 2012, at 2:57 PM, Pat Hayes wrote:

> 
> On Jun 14, 2012, at 12:39 PM, Ivan Herman wrote:
> 
>> Hey Gregg,
>> 
>> On Jun 14, 2012, at 17:48 , Gregg Kellogg wrote:
>> 
>>> On Jun 14, 2012, at 3:29 AM, Ivan Herman wrote:
>>> 
>>>> To avoid any kind of misunderstandings: my comment/question should not have a bearing on whether the document comes over to the RDF WG or not, ie, I do not consider that as a prerequisite for starting the whole procedure. Consider it as a comment that may result in active RDF WG issues on the draft either before or after the FPWD publication.
>>>> 
>>>> My questions are on the section on @graph, ie, section 4.9 (and tried to look at the API doc, too). They may be clarification issues but maybe missing features in the spec. Obviously, I look at this with an RDF, more exactly RDF Named Graph (put your preferred term here:-) goggle on. I also have some comments on the construct itself, see below.
>>>> 
>>>> Question 1: I do not understand the last example in the section, namely the lonely "http://www.markus-lanthaler.com/". There is some text there about additional meta data about Markus, but what would that mean in terms of TriG? Could you describe this? 
>>> 
>>> Yeah, I put this in here partly to provoke a reaction :),
>> 
>> Well, you were successful!
>> 
>>> and it should definitely be considered to be at risk. Given that the document will be an RDF WG spec, this can only be included if it is compliance with the rest of RDF Concepts and Semantics.
>> 
>> Yep. I think that minor entry should then be removed before going to FPWD.
>> 
>>> 
>>> It's in there because of two basic reasons:
>>> 
>>> 1) JSON-LD is an expression of Linked Data. The use of a bare IRI was to indicate that a separate resource might be named as part of a dataset that comprises the agregated linked resources. If it is a best practice to use IRIs to denote resources which describe themselves, then this use is in keeping with those principles.
>>> 
>>> 2) A problem that came up in WikiData is that you often want to describe a statement using separate provenance, so that a given statement (or collection of statements) could be considered to be in more than one layer/named graph at the same time. For example, a statement is given provenance as deriving from a particular source (e.g., Berlin population), came from some other source document, along with other statements and so forth. Basically, from my observation, this group has described a number of different, but seemingly mutually-exclusive, uses of named graphs. The notion of using an IRI to resolve the resource which is otherwise named was some attempt to hint at a way in which an external resource could be considered to be part of multiple layers/named graphs.
>>> 
>>> That said, it's not my intent to open the debate on how a set of statements might be considered to be in more than one named graph at the same time (other than by simply repeating the statements).
>> 
>> At the moment the discussion has not taken a direction that would require several named graphs to be mutually disjoint in terms of their triples. That is for the semantics.
> 
> No, the semantics talks of *sets* of triples. Of course two sets may overlap, ie have a subset in common. So the semantics is completely neutral on this issue, and will stay neutral. It is entirely up to whover defines a concrete syntax to specify how their syntactic rules work on this point. 
> ...
> 
>> 
>> I know the problem:-). 
>> 
>> Maybe worth repeating it for the RDF WG readers: If I take a simple graph of the form
>> 
>> <a> <x> <c> .
>> 
>> <p> <x> <r> .
>> 
>> Its bare bone JSON-LD format would be something like
>> 
>> [
>> { 
>>   "@id": <a>, 
>>   "<x>" : {"@id":"<c>", "@type":"@id" },
>> }
>> { 
>>  "@id": <p>, 
>>   "<x>" : {"@id":"<r>", "@type":"@id" } 
>> }
>> ]
>> 
> 
> Ahem. I have been keeping out of this whole JSON discussion as I really have no intention of every having anything to do with JSON for the rest of my natural life, but this example really gives me pause. The arguments for JSON were, as I recall, that it provided a *simpler* notation for RDF than, say, RDF/XML, and that it was very *natural* to use JSON to express RDF structure. If this example is typical, I would run screaming from JSON and stick to RDF/XML as a standard. Is it really this awful? What are we doing even bothering to even standardize such a monstrosity? 

I should have corrected this before. The JSON for those examples would be more like the following:

[
  { "@id": "a", "x": {"@id": "c"}},
  {"@id": "p", "x": {"@id": "r"}}
}

However, typically, you'd expect that the fact that <x> has the range of an IRI, not a literal, the "@id" bit would be defined with an external context, so the real-world representation would be more like the following:

[
  { "@id": "a", "x": "c"},
  {"@id": "p", "x": "r"}
}

I think that's a pretty reasonable representation. The expanded form would be what a processor would get after removing the context. Without either a context, or an expanded form, there's now way to know if "c" represents a string or an IRI otherwise.

> Ah well, consider this a rant, it doesnt need a reply. I will shut up now.

Hopefully this mollifies your rant just a little :)

Gregg

> Pat
> 
> 
> ------------------------------------------------------------
> 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 Sunday, 17 June 2012 22:24:25 UTC