Re: Defining "LD" (was Re: Branding?)

On 7/28/11 2:19 PM, Manu Sporny wrote:
> -cc: public-lod@w3.org
>
> Sorry, I don't think we should be cross-posting this discussion. Feel 
> free to add it back in, but until we have an idea of what we're doing, 
> I don't think it's helpful to pull the larger community in. Especially 
> since they don't know what we're trying to do with JSON-*D.
>
> On 07/28/2011 01:21 PM, Danny Ayers wrote:
>> "LD" meaning "Labeled and Directed" for JSON-LD works for me too.
>
> I have an issue with "Labeled and Directed" - try using it in a 
> conversation with a Web Developer that doesn't know about this area - 
> Linked Data, Semantic Web, etc. It will take quite a bit to explain to 
> them what "Labeled and Directed" means.
>
> Kingsley, Dave, Danny - what about:
>
> "JSON for Linking Data" - JSON-LD
>
> That way, the name itself is fairly self-explanatory and we don't 
> muddy the waters by using the "Linked Data" terminology in the spec's 
> name. 

Yes, but what happens to the work by Gregg and Bradley re. requirements 
[1] ?


> We can have a definition of "Linked Data" in the spec, and tell them 
> that is the ideal we want to move towards, but that the "JSON for 
> Linking Data" allows them to express Linked Data as well as other 
> types of non-Linked data. Thoughts?

How about: JSON-LD where "LD" is for "Linked Data". Then take advantage 
of this point from the requirements doc:
An IRI that is a label in a linked data graph *SHOULD* be dereferencable 
to a Linked Data document describing the labeled subject, object or 
property.

It doesn't state *MUST* which is why I always assumed it deftly resolved 
the Linked Data and Blank Nodes matter :-)

So we roll back to "LD" == Linked Data with Blank Nodes *accommodated*, 
but confined to the special quarters in this particular house.

Now, hopefully pulling Glenn back into this discussion, we should really 
focus the spec on the 80% issue of simple directed graph construction 
using JSON. Spec use case examples can deal with N-arity and other 
matters that are addressable via blank nodes. This spec should really 
boil down to JSON representation for:
<ObservationSubjectName> <SubjectCharacteristicName> 
<SubjectCharacteristicValueInLiteralOrReferenceForm> .
...


Links:

1. http://json-ld.org/requirements/latest/ -- JSON-LD requirements.

>
> -- manu
>


-- 

Regards,

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

Received on Thursday, 28 July 2011 18:33:15 UTC