W3C home > Mailing lists > Public > public-rdfa-wg@w3.org > April 2012

Re: Experimental RDFa extractor in JS

From: Gregg Kellogg <gregg@greggkellogg.net>
Date: Fri, 20 Apr 2012 11:59:20 -0400
To: Niklas Lindström <lindstream@gmail.com>
CC: Ivan Herman <ivan@w3.org>, public-rdfa-wg <public-rdfa-wg@w3.org>
Message-ID: <297DC811-28D0-49B7-9B9C-48054EA8B299@greggkellogg.net>
On Apr 20, 2012, at 8:23 AM, Niklas Lindström wrote:

> Hi Gregg,
> 
> 2012/4/20 Gregg Kellogg <gregg@greggkellogg.net>:
>> On Apr 20, 2012, at 3:52 AM, "Niklas Lindström" <lindstream@gmail.com> wrote:
> [...]
>>> Yes, that's what I do too, for exactly those reasons. The shape of the
>>> output is entirely based on the form of the input, i.e. using the same
>>> terms and CURIEs (populating @context as needed). One thing I haven't
>>> yet done, but plan to, is to merge descriptions about the same
>>> resource even if they're dispersed throughout the page.
>> 
>> Note that you can leave such merging to JSON-LD framing, which does this anyway.
>> 
>>> While that
>>> does deviate from the actual shape in the source page, it is so much
>>> better for consumption, and I think is to be expected. Another thing I
>>> don't do is any kind of coercion. Literals with datatype or deviating
>>> from any given @language are represented in expanded JSON-LD form.
>>> I've yet to decide whether to change that or make it configurable.
>> 
>> This might also be left to JSON-LD API methods. For instance, the "automatic" flag to compaction could generate the best context for you to use, and coerce your data for you. It can be expensive, though, and for any real application, a JSON-LD context matching the data could be provided to compact or frame.
> 
> At this point I'd like to stick to a strict and very simple solution,
> with one predicable result tree (based on the source RDFa structure,
> but merging anything dispersed). I'd like this to be lightweight and
> simple, with close to no API. The fact that this solution produces
> JSON-LD is a benefit, but it is basically skimmed data, mainly usable
> for simple things. I think of it mostly as an RDFa equivalent to the
> microdata-to-JSON approach. (And the merging I speak of is roughly
> corresponding to how that handles the @itemref stuff.)

For some reason, my point is being confused. I think the approach your taking is just great. My point was that if anything more complicated needs to be done, it can be left to JSON-LD tools. I'm all for keeping your implementation as simple possible, and be close to the form of the document you've produced.

If a developer wants to do more with the data than what you produce, the JSON-LD API has a number of useful tools. There should't be any direct dependencies between your tool and the JSON-LD implementations, leave the that up to a developer.

Gregg
Received on Friday, 20 April 2012 16:00:29 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 04:55:20 GMT