Re: JSON-LD Telecon Minutes for 2011-07-04

On 7/20/11 6:25 AM, Manu Sporny wrote:
> On 07/19/2011 11:50 AM, Gregg Kellogg wrote:
>> I think we're getting caught up in the definition of "Linked Data"
>> and the requirements for Linked Data in JSON. Certainly, to express
>> Linked Data as JSON, unnamed nodes are not necessary. However, as
>> language creators, we may need to take into consideration other
>> reference points. Finding a way to accommodate existing JSON practice
>> and make sense of it in the context of JSON-LD is also important
>> IMO.
> +1
>
> I'm still uncertain whether Kingsley is talking about the definition of
> "Linked Data" or the Requirements for Linked Data in JSON. I feel like I
> have a more firm grasp of where Glenn and Ted are coming from, but I'm
> still confused about whether we're talking about the definition for
> Linked Data or the Requirements for JSON-LD.

JSON-LD has to have a clear definition of Linked Data. Doing so makes 
JSON-LD crystal clear etc..

JSON-SD is what Gregg seeks, ditto yourself, as per my comments in the 
JSON-SD post (earlier).


>> If the JSON-LD spec says "Items SHOULD be named with an IRI" this
>> might imply that the processing steps do not need to consider the
>> case when it's not, or that authors using unnamed items (or even
>> items named with literals, for example) are somehow wrong. If an
>> author conceivably COULD name all nodes with an IRI that means that
>> they MUST.
> I would be fine with the statement of "Nodes SHOULD be named with an IRI".
>
> Our company is not going to follow that advice in practice. I would
> expect that well over 90% of our data will contain unlabeled nodes. I
> think many other Web developers are going to have unlabeled nodes as well.
>
>> I'd be fine with a statement somewhere that extolls the virtue of
>> pure Linked Data, but we need to take into consider the practical
>> considerations for JSON-LD authors.
> Agreed. I'm fine with telling people what "Real Linked Data(tm)" looks
> like.

There's no such thing as Linked Data (tm). It's extremely important for 
definitions to be as clear as possible. You see, and I've stated this 
many times, when TimBL penned the original Linked Data meme [1] , it was 
GOLDEN, and very clear (took some digest for most, but its was perfect 
in essence). When, as Sandro claims, he nudged TimBL into adding RDF and 
SPARQL to point #3, he basically broke the original Linked Data meme's 
coherence, defensibility, and bootstrap velocity by bringing 
implementations details into the main definition.

Now let's revisit TimBL's original Linked Data meme modulo: ", using the 
standards (RDF*, SPARQL)":

   1. Use URIs as names for things -- unambiguous names
   2. Use HTTP URIs so that people can look up those names -- make the
      names actionable
   3. When someone looks up a URI, provide useful information -- vague
      reference to a graph pictorial based representation of the URI's
      referent
   4. Include links to other URIs. so that they can discover more things
      -- reiterate i.e, reference other observation subjects (items of
      interest) by name.


In the above you have accommodation for JSON-SD and JSON-LD.

Now, remember a meme is about best practices. The meme above doesn't 
define the fundamental concept of Linked Data. It does delve into the 
mechanics of de-reference (indirection) and address-of operations.

Linked Data isn't conceptually new, by this I mean names that resolve to 
actual data addresses via indirection. What's new is the use of URIs as 
a powerful vehicle for Linked Data at InterWeb scales. Thus, if you want 
to make truly distributed data objects where the graph pictorial 
transcends machine, operating system, data access protocol, and data 
representation confines, you have to exploit de-referencable URIs as 
unambiguous names that resolve to graph pictorial based data 
representations of their referents. This is good old computer science 
enhanced via the use of contemporary technology in the form of URIs.



> As long as we can express unlabeled nodes via the specification, we're
> happy.

Keep it in the JSON-SD bucket.

>   If that means that we stop calling this JSON-LD and start calling
> it JSON-SD, then so be it.

Yes, that works very well!

>   I think the latter is going to be far more
> useful to Web Developers.

You are making subject commentary :-)
> -- manu
>


-- 

Regards,

Kingsley Idehen 
President&  CEO
OpenLink Software
Web: http://www.openlinksw.com
Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca: kidehen