Re: Request for FPWD via RDF WG of JSON-LD Syntax and API specs

Manu, greetings. 

Sorry if this is rather late, but I have only now read through these documents (not being a JSON maven, I had thought to leave this task to others.) Unfortunately there are some serious issues with the use of standard terminology, which I would urge you to consider carefully before publication, as they could have a seriously deleterious affect on the understanding of some readers and will likely  generate a great deal of needless confusion and misunderstanding. 

The most serious is a repeated confusion of the syntactic distinctions such as subject, object and property with semantic notions such as resource. For example, in [API] 3.2, we read

"blank node
a blank node is a resource which is neither an IRI nor a literal. Blank nodes may be named or unnamed and often take on the role of a variable that may represent either an IRI or a literal."

This is all quite wrong. A blank node is not itself a resource. It is a NODE which is neither IRI nor literal, and it definitely is NOT itself named.  It *refers to* a resource which may be named or unnamed, but that is quite different from saying it IS one. Again, it may refer to the same thing as an IRI or literal refers to, but it itself does not *represent* an IRI or a literal. 

Again, in 3.13.1:
" ... a key concept is that of a resource. Resources may be of three basic types: IRI, representing IRIs for describing externally named entities, BlankNode, resources for which an external name does not exist, or is not known, and Literal, which describe terminal entities such as strings, dates and other representations having a lexical representation possibly including an explicit language or datatype.

Data described with JSON-LD may be considered to be the representation of a graph made up of subject and object resources related via a property resource."

This is all muddled. Graphs are not made up from resources: they are made up from nodes and arcs.  Resources do not come in three types: you are here talking about the nodes and arcs of the RDF graph, not the resources that these various graph components *refer to*. Indeed, it is quite possible for an IRI, an blank node and a literal to all three refer to the same resource. 

------

[LD] does not have such egregious misuses of terminology, but it does have some confusing remarks. The Introduction says:

"A thing in this data network is typically identified using an IRI (Internationalized Resource Identifier), which is typically dereference-able, and thus may be used to find more information about the thing. The IRI allows a software program to start at one thing and follow links to other things in order to learn more about all of the things described on the Web."

Does "thing" here refer to the items which the data is about, or to the data items themselves? Neither interpretation makes sense. Consider for example http://dbpedia.org/resource/Honda_Civic, which refers to ("identifies") a car model, but dereferences to a Web page about that car model. If "thing" refers to the Web page, then its not what the page is about (at least, that is what the page itself says), but if it refers to the car model, then you can't get at that thing by dereferencing a web page. 

Section 3.1, line 11:
"A value is an object with a label that is not an IRI"

This is not technically wrong, but I would urge you in the strongest possible terms to reconsider using the term "value" for a graph node of any kind. This is horribly misleading, and will likely breed massive confusion. I think (your editors seem to be going to extraordinary lengths to pretend that you are not using RDF) that you mean here to refer to literal nodes, perhaps also allowing other possibilities. If so, then the use of "literal" (or a similar word) rather than "value" would be far clearer. Or at least call it something like "value node". (The problem here is that *any* node may be said to have a "value", which is what the node is being interpreted to mean or refer to. So calling one type of node a "value" makes this close-to-universal language usage completely meaningless or extremely confusing.) 

Finally, a pet peeve of mine regarding blank nodes.

[LD]  3.1 says

" Unlabeled nodes are not considered Linked Data." 

Says who? I didnt know there was a Ministry (Church?) of Linked Data. 

But 3.1.2 says:
"The example above does not use the @id keyword to set the subject of the node being described above. This type of node is called an unlabeled node and is considered to be a weaker form of Linked Data."

So, which is right? Is LD with blank nodes just weakly linked, or is it totally persona non grata, and excluded from consideration by definitional fiat? 

As you can probably tell, I find this aversion to the (useful and harmless) notion of blank nodes rather silly, as well as simply false: a great deal of actual linked data does have blank nodes in it, and this is likely to continue and even increase as time goes on. It is telling that even you, in this short document, weren't able to conveniently avoid them. 

But whatever your beliefs on this topic, my point is that the document ought to be consistent about it. 

Best wishes

Pat Hayes


On May 23, 2012, at 10:45 PM, Manu Sporny wrote:

> During the RDF WG telecon today, there was a concern that the RDF WG
> should not publish the JSON-LD Syntax document if there wasn't a clear
> understanding of how one converts to and from RDF. That algorithm
> resides in the JSON-LD API. There were two alternatives that were proposed:
> 
> 1) Move the toRDF() and fromRDF() API calls (and all necessary IDL) from
> the JSON-LD API into the JSON-LD Syntax document.
> 2) Publish both the JSON-LD Syntax specification and the JSON-LD API
> specification via the RDF WG at the same time.
> 
> This request was made because the RDF WG does not believe that it should
> publish a specification that does not make some sort of normative
> statement about how to serialize RDF. The JSON-LD Syntax specification
> normatively references the JSON-LD API specification, which contains the
> normative algorithm for converting to/from RDF.
> 
> The first option is problematic because it muddies the clear delineation
> we have now between JSON-LD "the language" and JSON-LD "the API".
> 
> The second option is more reasonable, but requires us to publish the
> JSON-LD API when we are still 3-4 months away from finalizing it. Doing
> this would still be okay since FPWDs don't have to be "complete" by any
> stretch of the imagination.
> 
> Therefore, this is a request that the RDF WG publish both the JSON-LD
> Syntax specification and the JSON-LD API specification as FPWDs.
> 
> The JSON-LD Syntax specification can be found here:
> http://json-ld.org/spec/ED/json-ld-syntax/20120522/
> 
> The JSON-LD API specification can be found here:
> http://json-ld.org/spec/ED/json-ld-api/20120524/
> 
> If any member of the Linked JSON Community Group would like to object to
> this request, please do so before next Wednesday at 11am ET. Keep in
> mind that an objection will result in FPWDs not being considered for
> publication by the RDF WG.
> 
> The RDF WG will re-visit the request next week during the telecon.
> 
> -- manu
> 
> -- 
> Manu Sporny (skype: msporny, twitter: manusporny)
> Founder/CEO - Digital Bazaar, Inc.
> blog: PaySwarm Website for Developers Launched
> http://digitalbazaar.com/2012/02/22/new-payswarm-alpha/
> 
> 

------------------------------------------------------------
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, 24 May 2012 20:05:06 UTC