W3C home > Mailing lists > Public > public-linked-json@w3.org > September 2011

Re: Why Framing and Normalization

From: Ivan Herman <ivan@w3.org>
Date: Sat, 3 Sep 2011 18:19:52 +0200
Cc: public-linked-json@w3.org
Message-Id: <1F85AFB2-F47A-408C-8B6C-C343CE0F6F4D@w3.org>
To: Dave Longley <dlongley@digitalbazaar.com>

On Sep 3, 2011, at 17:46 , Dave Longley wrote:
>> 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#>
>> 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.

I understand all this. And I did _not_ mean to use SPARQL literally or through an implementation, sorry if I was not clear. However, my feeling is that the concepts of SPARQL might be useful and maybe even better in framing (sic!) the whole idea and the algorithms. For example, SPARQL gives you a separation of the patterns for the triples on the one hand, and what you construct out of it on the other; that does not look like a horribly complex concept to me, and may be a better way of describing what we need to achieve. The concept of a variable made explicit is useful in this respect; it is, in some way, hidden in the current frame language. Again, I do not think this is something of a huge complexity (after all, many of the developers have been exposed to SQL which operates with similar concepts). Also, describing the algorithm in terms of a graph matching on the pattern and then using the variable to construct a frame does not look like very complicated. Of course, there area a number of SPARQL features that, at least at first, we would not have (OPTIONAL, UNION, FILTER, GRAPH, FROM, etc), which might keep things simple. And, I presume, the concepts should be cast into a JSON syntax.

I realize that I am hopelessly influenced by my background and, from where I stand, the current frame algorithm seems to be way more complicated than describing the same effect with graph matching and construction. But that may be only me...



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 16:20:17 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:18:32 UTC