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

Re: Why Framing and Normalization

From: Andy Seaborne <andy.seaborne@epimorphics.com>
Date: Fri, 02 Sep 2011 09:11:19 +0100
Message-ID: <4E608FA7.4000902@epimorphics.com>
To: public-linked-json@w3.org

On 01/09/11 16:05, Dave Longley wrote:
> On 09/01/2011 03:27 AM, Andy Seaborne wrote:
>> On 01/09/11 06:02, Manu Sporny wrote:
>>> 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/.
>> This is a strange statement - the framing example shows that the result
>> is that to access the chapter title, you have to know,
>> library->book->chapter->title. You can't just get the chapter title
>> from a book without going through the whole library; books not in
>> libraries don't exist. Graphs work named/indexed access, not by rooted
>> traversal.
> If you want all the books and don't care about libraries, then just
> frame the books. The given example frame was only one possibility,
> here's another:
> var frame = [{
> "@context": {
> "@coerce": {
> "@iri": ["book", "chapter"]
> },
> "author": "http://purl.org/dc/elements/1.1/author",
> "title": "http://purl.org/dc/elements/1.1/title",
> "description": "http://purl.org/dc/elements/1.1/description",
> "Book": "http://example.org/vocab#Book",
> "book": "http://example.org/vocab#book",
> "Chapter": "http://example.org/vocab#Chapter",
> "chapter": "http://example.org/vocab#chapter"
> },
> "@type": "Book",
> "chapter": [{
> "@type": "Chapter"
> }]
> }];
> This frame will give you all the books in an array. Then just iterate
> over them and get their chapters' titles. No libraries involved. Framing
> is designed to allow you to filter and structure the data how you want
> it; not everyone will want the same thing.

I agree not everyone will want the same thing.  The case here is that 
the publisher and consumer of data want to see things a little different 
(but not a lot).

If the publisher publishes library framing, and the app wants books, 
something has to convert.  Maybe it's the publisher with different APIs 
but that seems a burden on the publisher. Maybe it's the app code - but 
the app code is then aware that the framing is library-book-chapter.

Framing -> framing services?

Received on Friday, 2 September 2011 08:11:53 UTC

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