Re: Why Framing and Normalization

On 09/03/2011 03:45 AM, Ivan Herman wrote:
> 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.

Correct.

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

And a good thought; Manu actually had the same thought at Digital Bazaar 
a little while back. One could say that there is some reinventing of the 
wheel here depending on how you look at it. What I mean is that the 
concept of preserving structure would still be something new that would 
have to be added to the SPARQL output.

Despite some measure of reinventing the wheel (or at the very least, 
reusing parts of a similar car), we decided that it might be a bit much 
to require an entire SPARQL stack in order for people to use JSON-LD 
framing. In part because the framing feature itself can stand alone 
fairly easily, but also because we expect SPARQL to be a wholly foreign 
technology to most JSON developers and have a much higher learning curve 
than building a frame that looks just like the objects you work with in 
your code.

There is also something to be said about not requiring a SPARQL 
implementation in JavaScript or in the web service that you acquire your 
data from. For example, in PaySwarm, we built a wordpress plugin to 
serve web pages that contain listings of assets (in this case blogged 
recipes) for sale marked up in RDFa. Now, there is also other data 
marked up in RDFa on the web page that the PaySwarm purchase process is 
totally disinterested in, but neither the PaySwarm code or the wordpress 
site needs a SPARQL stack in order for the PaySwarm code to obtain the 
data, frame just the listing, and then use it when performing the 
purchase of an asset.

I don't think that we should require an understanding of SPARQL or 
access to an implementation of it in order for people to use the framing 
feature in JSON-LD. Using SPARQL might not sound like a big deal to the 
RDF community, but I suspect that it would be a tougher sell in the JSON 
community. However, none of this means that it isn't a good idea to add 
a framing feature to SPARQL.

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


-- 
Dave Longley
CTO
Digital Bazaar, Inc.

Received on Saturday, 3 September 2011 15:47:36 UTC