Re: Why Framing and Normalization

On 9/3/11 8:04 PM, Manu Sporny wrote:
> On 09/03/2011 03:43 PM, Danny Ayers wrote:
>> Ok, I suppose the crux of the disagreement is that while you see :
>>
>> (flexible format + framing) = easy for developers
>
> I'm sorry Danny, I do not think that is the crux of the disagreement. 
> What you write above is not a good summary of what Dave is saying... 
> you seem to be assuming that developers need to rely on framing for 
> JSON-LD to be useful. Here is a breakdown of how it should work in 
> practice, starting from a simple example, moving up to a more complex 
> example:
>
> JSON-LD allows this to be published:
>
> {
>    "name": "Danny Ayers",
>    "homepage": "http://dannyayers.com/"
> }
>
> and then JavaScript developers can do the following with it:
>
> person = JSON.parse(THE_OBJECT_ABOVE);
> console.log("The name of the person is: "+ person.name);
>
> Note that there is absolutely no need for framing or RDF or knowing 
> about graphs or anything Semantic Web-y. You do need to know the exact 
> structure of what the Web Service is publishing - but most JSON folks 
> seem to be cool with that (in 2011). You just use the JSON as-is and 
> everyone is happy - except for the people that care about Linked Data.
>
> So, the question becomes "What can we do to keep the people that are 
> using JSON happy while making the Linked Data people happy as well?". 
> The JSON-LD answer to this is:
>
> {
>    "@context": "http://example.com/vocabs/person",
>    "name": "Danny Ayers",
>    "homepage": "http://dannyayers.com/"
> }
>
> The people that don't care about Linked Data, and only care about JSON 
> can still do this:
>
> person = JSON.parse(THE_OBJECT_ABOVE);
> console.log("The name of the person is: "+ person.name);
>
> Note that there is absolutely no need for JSON-LD APIs or framing in 
> this example. Also note that the Linked Data people can 
> follow-their-nose to the @context and expand the object out into 
> something that has more meaning to them, specifically:
>
> _:bnode1 foaf:name "Danny Ayers".
> _:bnode1 foaf:homepage <http://dannyayers.com/> .

So far that's RDF. Again, using blank nodes isn't a clear way to make a 
statement about Linked Data.

>
> So, now both JSON folks and Linked Data folks are happy.

I think you mean JSON and RDF folks. Here's why, you have an EAV/SPO 
based structure, but no comments above URI behavior.

RDF != Linked Data. It is an optional mechanism for creating Linked 
Data. Ditto JSON-LD.

Linked Data is the product of a specific type of directed graph. One 
comprised of de-referencable URIs. Basically, the use of URIs for 
indirection (de-reference) and address-of operations.

We covered all of this en route to the requirements doc .

> Also keep in mind that the JSON folks still don't have to care about 
> framing or RDF or graphs.

They care about accessing data structures comprised of attribute=value 
pairs that are ultimately graphs when you factor in all the pieces e.g., 
location of the chunk of data, and a label/name for the chunk of data.

> The Linked Data folks have to care about RDF and graphs - but that's 
> cool, because they already care about that stuff. So, now both camps 
> are happy.

Linked Data isAbout directed graphs comprised of de-referencable URIs in 
the Entity (Subject), Attribute (Predicate), and Value (Object) slots 
optionally.

You can easily produce RDF based directed graphs that do not have 
de-referencable URIs. In short, that used to be the norm until the 
Linked Data meme started to propagate.

Conflating RDF and Linked Data serves no constructive purpose. I made 
this point repeatedly.

>
> Each solution that you have proposed breaks this fundamental principle 
> - don't muck around with what makes people happy.
>
> You can't ask JSON developers to start publishing their data with a 
> very restrictive structure because /they do not care about RDF or 
> SPARQL or Linked Data/ right now. If they believed in it, they would 
> just use TURTLE - not JSON.


Developers care about structured data and you'll ultimately find that if 
you are going to consider conflating anything your best best would be 
that: structured data == some kind of graph data structure, ultimately.

The issue is that JSON developers want to work with JSON at the syntax 
and data serialization levels. Achieving this goal isn't in any way 
mutually exclusive with regards to graph based data structures.

Simple question: what's wrong with this object accessible from the URL: 
http://graph.facebook.com/kidehen ?

{
    "id": "605980750",
    "name": "Kingsley Uyi Idehen",
    "first_name": "Kingsley",
    "middle_name": "Uyi",
    "last_name": "Idehen",
    "link": "https://www.facebook.com/kidehen",
    "username": "kidehen",
    "gender": "male",
    "locale": "en_US"
}


Would a JSON developer have any problems with the data above?
Isn't the structure above a graph?
Doesn't the Data Object have an ID?
Doesn't the Data Object Representation have an Address?
Couldn't an RDFer turn that into RDF?
Adding a de-referencable URI based Name, derived from the ID that 
resolves to the Data Object Address, starts the Linked Data journey. 
Repeat across some of the literal values in the structure above and the 
webby-ness of the emerging Linked Data structure increases.



>
>> I can't help seeing :
>>
>> (flexible format) = difficult for developers
>
> I reject the statement above - JSON is an incredibly flexible format - 
> it isn't difficult for developers. Therefore having a flexible format 
> does not automatically mean that it will be difficult for developers.

You are arguing about syntax and formats. Neither really matter. Triples 
are extremely flexible, irrespective of syntax sugar.

>
> The statement above doesn't capture the nuance of this issue. If I 
> were arguing your point, I'd say:
>
> The flexibility offered by JSON-LD may be difficult for JSON 
> developers transitioning from a JSON-only world to a Linked Data 
> world. That is, they will need to understand how graphs work.
>
> I would agree with that statement, but luckily, we try very hard to 
> make it so that they don't have to make the transition unless they 
> want to do so. If they want to care about Linked Data, they're going 
> to have to learn about graphs of information.
>
>> (framing) = difficult for developers
>
> Again, this does not capture the nuances involved. Which developers? 
> JavaScript developers? SPARQL developers? Linked Data developers? Why 
> is framing difficult? Why is query-by-example (which is what framing 
> emulates) more difficult than learning a sub-set of SPARQL? Who is 
> your audience?... because it doesn't seem like it is JSON developers. 
> The statement above is just as spurious as:
>
> SPARQL = difficult for developers, or
> RDF = difficult for developers
>
> Most importantly, what are the alternatives to framing that don't 
> break the "Don't muck around with what makes people happy." design 
> principle?

If you split up the spec as already suggested. And also make it crystal 
clear that framing has no bearing on conformance the distraction of 
framing will vanish.

>
> I have yet to see a single proposal that takes both of these concerns 
> into account:
>
> 1. Make JSON developers happy.
> 2. Make Linked Data developers happy.

Linked Data only cares about:

1. Triples
2. De-referencable URIs
3. Negotiable data serialization formats .
>
> All of what you have proposed thus far arguably achieves #2 - but 
> fails to achieve #1.
>
> -- manu
>


-- 

Regards,

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