Re: Why Framing and Normalization

On 2 September 2011 23:42, Dave Longley <dlongley@digitalbazaar.com> wrote:
> 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.

I will be very impressed if typical developers don't need knowledge
about the data that's been delivered (it's feasible in the RDF world,
but I've not seen anything comparable elsewhere).

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.

Ok, but there you're replacing custom code (which will presumably will
be written using libraries and code with which the developer is
familiar, with the JSON-LD framing system, with which (at least in the
first instance) they won't be familiar.

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

Right, I totally agree with that. But the current approach seems to
have drifted quite a long way from that. Before they can interact with
the data as simple objects they have to transform it into simple
objects.

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

I wouldn't highlight any specific aspect, in the same way I wouldn't
highlight any specific aspect of working with RDBs or XML as a burden.
But if your objective is to build an application, you are more likely
to favour data sources that don't involve learning a new technology.

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.

If they really are the same structures they are relying on in the code
they write, why can't they use their existing techniques?

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.

That's great, but does rely on having framing in the code path. I'm
not convinced that step is necessary (a less complex format would
allow more direct access to the object structures) and suspect it may
put developers off.

Contrast with XML format data. If you want to turn that into objects
in your favourite language you could use SAX, DOM or any of the many
variants, transform it with XSLT into another format you can already
receive, or even just use regular expressions. But you get to choose
how to do that mapping to your objects. How would you feel if you
*had* to use XSLT? I'm sure whatever JSON-LD ends up like people will
develop other ways of accessing the data, but what bothers me is the
design of the format is being heavily influenced by this one
particular method: it doesn't matter what goes over the wire because
it can be made simple with framing.

Ok, it could be argued that the model underlying typical XML data is
generally simpler than the graphs of RDF. But that entirely depends on
the application, and I think it's likely that the majority of data
that is delivered as JSON-LD is likely to be simpler than arbitrary
RDF. Again it could be argued that you can do things with RDF that
don't require prior knowledge of the structures in the data. But if
the consumer has those facilities, why bother using JSON at all - just
pass Turtle or whatever. Why would you choose a system that offers
simple structural access when you don't need it.

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

Different trade-offs, yep.

Cheers,
Danny.

-- 
http://dannyayers.com

Received on Friday, 2 September 2011 23:23:22 UTC