- 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