Re: Why Framing and Normalization

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, now both JSON folks and Linked Data folks are happy. Also keep in 
mind that the JSON folks still don't have to care about framing or RDF 
or graphs. 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.

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.

> 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.

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?

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.

All of what you have proposed thus far arguably achieves #2 - but fails 
to achieve #1.

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny)
Founder/CEO - Digital Bazaar, Inc.
blog: Building a Better World with Web Payments
http://manu.sporny.org/2011/better-world/

Received on Sunday, 4 September 2011 03:05:08 UTC