Shared publicly  - 
Great input on JSON-LD and "Linked Data" from Kanzaki-san.
KANZAKI Masahide originally shared:
Noticed recently that there are some arguments that Linked Data cannot have any blank (unlabelled) node in JSON-LD discussion. No way. We have whole bunch of Linked Data sets that contain blank nodes to give some parts of records structure.

Rejecting blank nodes because "the cost is high" sounds too data consumer oriented, something similar to Draconian error handling in XML.

It's OK to define some restrictions for a particular syntax, but do not define "What is Linked Data" just for that syntax.
I have a sympathy with +Dave Longley's post at
Re: Branding? This message : [ Message body ] [ Respond ] [ More options ]; Related messages : [ Next message ] [ Previous message ] [ In reply to ] [ Next in thread ] [ Replies ]. From : Dave Longley...
Mark Russell's profile photoKANZAKI Masahide's profile photoKingsley Idehen's profile photo
Kanzaki: I am sure you understand that in a nuanced laced conversation there is a lot of grey. The original Linked Data meme is very clear about the shape and form of Names. They have to resolve to representations of their referents.

Blank Nodes are a Hybrid case. You don't need Hybrid cases at the front door of a very specific concept if bootstrap is your fundamental goal.

See this example: . Its the BBC's Wild Life Ontology. It has Blank Nodes. Does that add value to comprehending Linked Data or does it add complexity re. comprehension?

Anyway, note that this thread which shows a conclusion to the matter: :-)
+Kingsley Idehen, it doesn't matter what LD in JSON-LD stands for. The trouble is that "what is Linked Data" is defined there, and it excludes blank nodes.

Of course, blank nodes don't add value to the graph, but are quite natural way to express n-ary relationship. Consider following RDFa:

<div vocab="">
<p about="#productId">Price:
<span rel="price">
<span property="value">1000</span>
<span property="unit" content="JPY">円</span>

My two cents are no publisher will want to add URI to the object of "price" property. It's OK to say this RDFa cannot be converted to JSON-LD, but not acceptable to claim this is not a Linked Data.

Call the syntax whatever the community like, but don't define the Linked Data itself there, that's beyond the syntax community issue. (I guess "Linked Data" in JSON-LD requirement to be LEAV (Linked Entity-Attribute-Value), LT (Linked Triples) etc)
Also note, I am not in the Syntax business. That's one of my permarants about Linked Data. I am only interested is clear descriptions. The definition of Linked Data is clear.

Anyway, as you can see from the JSON-LD mailing list this matter is resolved.
+Kingsley Idehen of course, not everyone has to understand English. Someone can define "Basic English" or "Plain English" for better inter-culture communication, but should not claim it IS THE English.

I'm not able to read all long-rich messages in the list, but the resolution seems just about what's LD in JSON-LD, not about the definition of Linked Data.

I know you (and many others) have advocated the importance of dereferencable data, and I agree with that :) But I believe bnodes should be allowed there to express n-ary relationship, unless some new constructs for n-ary would be introduced into RDF.
The issue is that people are conflating directed graph based data representation with a specific kind of graph based data representation. Linked Data is the by product of a specific kind of directed graph used as the basis for "whole data representation".

There is nothing about Linked Data that all of sudden mandates it as the sole mechanism for directed graph based data representation.

There is nothing about the concept of "Data" that all of a sudden makes "Linked Data" the only kind of Data.

TimBL penned a meme about how to use AWWW (Architecture of the World Wide Web) to unveil another dimension of Web interaction and exploitation. Basically, what increasingly being understood as the Web's Data Space dimension (a view point I've expressed for years now).

TimBL's original meme was crystal clear, and the language deliberately simple albeit applied to an abstract concept. This meme was about Linked Data at InterWeb scale.

The problem with blank nodes is that they don't fit into the InterWeb scale requirement of Linked Data if you take you cues from TimBL's original meme. The meme was all about URI based Names that resolve to Representations of their Referents. The representation in question was described as being "useful". Thus, whether a URI de-references to a machine readable or a human readable description of its Referent, it must resolve, and do so at InterWeb scale.

Takes the InterWeb out of the Linked Data meme and you have more wiggle room for blank nodes since you can make them resolve within the context of a local data space. We've actually done that for years, and so have a few others.

The real problem with blank nodes is aptly covered in a post by Richard [1]. His post basically highlights why blank nodes shouldn't be at the front door re. introduction and bootstrap of Linked Data, amongst other things.


1. -- a post about problems with blank nodes
Sure, a product information should be resolved to its representation, but that representation would be a collection of statements, and some of which can have structured values. These structured values, as part of the representation of a product, do not have to be resolved to another representation by themselves.

I know Richard's post, and it doesn't exclude bonodes for n-ary relationship.
My reference to Richard's post wasn't about N-arity. It was about the fact that Blank Nodes due to their Hybrid nature introduce problems re. Linked Data.

I understand N-arity and how blank nodes provide a solution.

My point remains that blank nodes don't really fit naturally into TimBL's meme re. InterWeb scale Linked Data where URIs resolve to Representation of their Referents across Data Spaces plugged into the WWW. That's my point.

I am not talking about a broad concept re. directed graph based data representation and N-arity.

The problem is that we are trying to squeeze too many things into the narrow Linked Data bucket for the wrong reasons.

The most important thing we can all do for the Linked Data meme right now is let it blossom without confusion that arises from conflation.
In addition to the above, here is a typical URIBurner based page showcasing the issue with blank nodes when dealing with InterWeb scale Linked Data: .

Notice that our skolemized URIs only work from our data space (where URIBurner runs). To see what I mean do the following:

1. Click on a skolemized blank node URI
2. Click on the @href associated with the about link
3. Observe the nature of the skolemized URI.

Repeat the same steps above using a non blank node URI e.g: .

Linked Data is about References that resolve across Data Spaces. Blank Nodes do not resolve across Linked Data Spaces, at InterWeb scale. That's my fundamental point.
I know what your comments and Richard's post mean (n-arity was just an example even that post doesn't totally exclude bnode), but these are quite data consumer oriented views.

See the previous RDFa example. Do you say it's not in the Linked Data Spaces? If so, there is a serious gap between what usual data providers think is Linked Data and what (some) data consumers think.
Put it this way, we generally accommodate but discourage blank nodes re. Linked Data. None of our tools balk at blank nodes. At the same time, we don't want them at the front door of the Linked Data meme due to the inertia they introduce.

Whenever blank nodes enter the conversation you're in for a long thread that ultimately blurs matters. That's the big issue.
If you ever figure out how to use JSON-LD or any other tool to make tags in G+ let me know!
G+ needs to publish an API before any serious innovations (of the productivity enhancing variety) can happen outside Google.
+Kingsley Idehen, agreed that no blank node is better. My point is that defining Linked Data (in general, not just for JSON-LD) as "A subject MUST be labeled with an IRI" is very discouraging for data publishers. I guess we are saying almost the same thing (at least in principle) from different point of view.
I am for language that says:
A subject SHOULD be labeled with an IRI.

I made a comment about an old +Pat Hayes meme [1] re. Literal Subjects. Basically, another example of RDF over extension via narratives that had many thinking RDF inside DBMS instead of RDF based Resources being imported, indexed, plus options for SPARQL based query access.

So yes, I am for:
A subject SHOULD be labeled with an IRI. Rather than:
A subject MUST be labeled with an IRI .

+Manu Sporny please note my comments above.

It boils down to using: "" ^^ xsd:AnyURI, to explicitly type a literal in Subject slot as a URI. This takes away current ambiguity associated with URIs since we can then explicitly type: URINames and URIAddresses.


1. -- +Pat Hayes meme (which once divorced from RDF inside the DBMS which never happens anyway, solves the problem).
Add a comment...