Why Framing and Normalization (was: Re: What is the JSON-LD API?)

On 08/31/2011 06:23 PM, Danny Ayers wrote:
> So essentially this is a transformation language & engine. Doesn't the
> fact that this level of engineering is needed suggest that the input
> format is too complex?

You could look at the framing feature as a transformation language and 
an algorithm, yes.

It's not the input format (JSON-LD) that is complex - it's graphs. 
Getting a regular structure out of a graph is a /very hard problem/.

Here are the options:

1) Have one single way of expressing graphs in JSON,
2) Give developers the flexibility to work with JSON in the way that
    they do today.

Pick one, because you can't have both. If you believe that you can have 
both, then you're going to have to propose a solution that achieves both.

That choice impacts adoption. I hope that it is clear that JSON-LD 
adopted #2 - because we care about Web publishers and developers first 
and foremost. Not because we primarily care about triples, RDF and ease 
of implementation (although, those are concerns as well).

Publishers aren't going to care about the implementation complexity of 
framing and normalization because /publishing JSON-LD is easy/. Add 
"@context" to your object and you're done.

Developers aren't going to care how complicated the nuts and bolts are 
that make the JSON-LD API work because they're just going to be using 
just four calls (if they need to use any at all): jsonld.expand(), 
jsonld.compact(), jsonld.frame(), and jsonld.normalize() - that's it. If 
you're only interfacing with a single Web Service, then all you need is 
JSON.parse().

Think about TLS - implementing it is incredibly difficult, but 
developers don't complain (much) when using an API to access it's 
functionality. Most people that browse the web and publish documents via 
HTTPs also don't care at all how it works - they see the padlock icon, 
they feel safe. Our job is to make this stuff feel as transparent as 
possible.

Implementers are going to have a hard time with implementing framing and 
normalization /because they are hard problems to solve/. These have 
always been hard problems to solve, which is one of the reasons that 
nobody has solved them yet. The RDFa API punted on framing because it 
was a hard problem. The majority of the SemWeb community (modulo folks 
like +Gavin Carothers and Jeremy Carroll) punted on graph normalization 
because it was a hard problem.

We have solved /and spec'd/ both of these hard problems not because we 
love spending hundreds of hours of painful work figuring out a correct 
solution, that is implementable and performant - but because /we needed 
the features/. Framing and Normalization may seem esoteric to people 
that don't need it - but you can't develop a system for long without 
running head-long into this particular brick wall (framing and 
normalization).

If you care about semantic web provenance, digital signatures, financial 
system security, government accountability, graph diffing, graph 
equality testing or anything that requires you to make a canonical 
byte-stream of a graph - you need normalization.

If you want to read data into your Web Service in /any/ graph format, 
but you want to write simple code to validate the contents of the graph 
- you either need framing OR you need SPARQL plus a performant Graph 
Store. The first is a fairly cheap investment (download the free source 
code and shove it into MySQL or MongoDB). The second is /very/ costly, 
both in developer training time and in capital necessary to purchase a 
solution or develop one in house that is of the same quality that the 
800 lb. gorillas have at their disposal.

If you are going to criticize JSON-LD as being "too complicated" because 
it has framing and normalization, please provide an alternative that 
will work for the people that care about the two paragraphs above.

To approach it from another direction, with another technology: I think 
WebGL is stupid and not that revolutionary - but I can also see why it 
is incredibly useful to game developers and UI developers because I 
understand the use case.

-- 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 Thursday, 1 September 2011 05:02:38 UTC