W3C home > Mailing lists > Public > public-linked-json@w3.org > September 2011

Re: Why Framing and Normalization

From: Dave Longley <dlongley@digitalbazaar.com>
Date: Fri, 02 Sep 2011 17:42:15 -0400
Message-ID: <4E614DB7.2080007@digitalbazaar.com>
To: public-linked-json@w3.org
On 09/02/2011 12:33 PM, Danny Ayers wrote:
> On 2 September 2011 18:04, Dave Longley<dlongley@digitalbazaar.com>  wrote:
>> The publisher can publish JSON-LD in whatever format they want to. It is the
>> applications that must do whatever framing is appropriate for their
>> application. Applications simply expect an incoming graph and are agnostic
>> about its JSON structure. All of the code for the application will be
>> written according to an expected particular structure; that application
>> simply frames incoming data according to it.
> This is what I don't get. Let's say the publisher publishes data in an
> arbitrary format. The consumer-developer will have to write custom
> code to make the data match their application requirements.

Consumer-developers must always write custom code to make incoming data 
match their application requirements. Their starting point could be 
reading documentation on how the data is published and then writing 
whatever code is necessary to make it conform to their application 
requirements. They may also have to stay up to date with how the 
publisher's data structure changes. *Or* they could skip that step 
entirely, receive the data as a graph in any structural format 
whatsoever, and then make it conform to the structure that best suits 
their application by using standard JSON-LD framing. All they need to do 
is write the frame that matches the structure of the objects they want 
to work with -- which is not a difficult task. So long as the input is a 
directed Linked Data graph, JSON-LD framing can shape the data into the 
appropriate structure for the consumer-developer's code.

Something to keep in mind with JSON-based development is that your code 
essentially works with the serialized form of your objects. This is what 
is so attractive about JSON; the serialization feels just like the 
objects that you are interacting with. In fact, languages like 
JavaScript and Python let you use the serialization directly in your 
code -- as a native part of the language. We don't want people to lose 
that feeling when working with JSON-LD. We just want to add support for 
Linked Data so that we can link together all of the now disparate 
objects that are floating around on the web.

> With the
> current JSON-LD, the format is relatively complex but the developer
> can make it match their requirements using framing. To do that they'll
> have to learn how to use framing - a new little language which really
> requires some knowledge of the RDF model. I don't see how this system
> makes things easier for the developer.

What knowledge of the RDF model, specifically, would they have to know 
that you consider a burden? Consumer-developers are going to be working 
with objects that have properties which point to more objects. Frames 
simply list out the structure of those objects; the same structure that 
consumer-developers will be relying on in the code that they write. To 
me, it seems very natural. In my experience, it has also been natural in 
practice so far. In the current PaySwarm implementation we parse RDFa 
from web pages into flat JSON-LD, and then we frame the results 
according to the objects that we use in our code. There's no "structure" 
at all (other than the graph) in the published RDFa, but we don't have 
to care about that as a consumer. If we hit a web page that does offer 
us JSON-LD instead of RDFa, and they can frame the data the way we want 
it, that's great. But our code works and uses a single code path regardless.

> An alternative that involves
>> framing via web services has been discussed briefly on the mailing list in
>> this thread (I believe):
>> http://lists.w3.org/Archives/Public/public-linked-json/2011Aug/0052.html
> It makes more sense if the work's done by the publisher, this is
> closer to the linked data API kind of idea.

I don't have a problem with supporting both (framing on the consumer 
side and framing via a publisher service). If a publisher wants to 
deliver JSON-LD and support an interface for a consumer to provide a 
custom frame for it, go right ahead. The publisher will end up making 
the JSON-LD Framing API call on their side instead of the consumer 
having to do it. However, if a consumer wants to frame something on 
their own, they can make the same call on their end. There are 
advantages to both approaches.

Dave Longley
Digital Bazaar, Inc.
Received on Friday, 2 September 2011 21:42:41 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:18:32 UTC