Re: Why Framing and Normalization

On 09/02/2011 04:11 AM, Andy Seaborne wrote:
>
>
> 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.

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

-- 
Dave Longley
CTO
Digital Bazaar, Inc.

Received on Friday, 2 September 2011 16:05:24 UTC