- From: Andy Seaborne <andy.seaborne@epimorphics.com>
- Date: Fri, 02 Sep 2011 09:11:19 +0100
- 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?
Andy
Received on Friday, 2 September 2011 08:11:53 UTC