Re: Why Framing and Normalization

Dave,

I think I understand all what you say, but I have a question. When an application defines its own frame, isn't it correct that he/she also defines the subset of the incoming data that he/she is interested in? What I mean is that some part of the incoming data is, conceptually at least, thrown away. This is not a problem: at least in the RDF world it is considered as normal that a specific RDF graph may contain a bunch of triples that, for a given application, is without interest. I would expect the same for JSON-LD data.

If so... the way I view framing is that, in fact, it is a special form of a query language or, to be more specific, a special form of a SPARQL CONSTRUCT. It is special because

- it is simpler than SPARQL (no filters, no graphs, etc)
- it has the additional feature that the return graph, encoded in JSON-LD, has to follow the structure of the query and not only the triples

Which actually raises the question in my mind whether it is not easier to formulate framing in terms of a subset of SPARQL (why reinventing the wheel?) with that additional requirement. To take the example in the document, and using a pseudo SPARQL syntax for now, what we have is

PREFIX vocab <http://example.org/vocab#>
JSON-CONSTRUCT *
WHERE {
  ?l a vocab:Library ;
     vocab:contains [
       a vocab:Book ;
       vocab:contains [
         a vocab:Chapter 
       ]
     ] .
}

It is a pseudo-syntax and, probably, transferring it back to the JSON syntax would be very similar to what we have now except for the variables. But I wonder whether we could not reformulate the whole algorithm by relying or (or be inspired by) the SPARQL concepts and algebra (instead of having to redo everything ourselves) with the additional feature of structure-preserving the output in JSON LD.

Just a thought...

Ivan


On Sep 2, 2011, at 18:04 , Dave Longley wrote:

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


----
Ivan Herman, W3C Semantic Web Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
PGP Key: http://www.ivan-herman.net/pgpkey.html
FOAF: http://www.ivan-herman.net/foaf.rdf

Received on Saturday, 3 September 2011 07:46:13 UTC