On 28/02/07, Stefano Mazzocchi <[EMAIL PROTECTED]> wrote: > Guys, please, let's color the bikeshed another time.
Point taken. For what it's worth, I don't actually disagree with Ben, RDFa does seem a useful way of publishing RDF. There are a couple of tangible points nearby though that I ought to mention. > There is really no point in arguing which approach is better to RDFize > information: if it works for you, great, if not use something else that > does. And if nothing does, create your own. Agreed, with one reservation. I think it's useful to make the distinction between scraping and parsing. I just posted to the microformats list on this point [1]. In that context and whatever the extraction mechanism used, if a HTML document includes a profile URI (as described in the HTML spec) the extracted data is known to follow the publisher's intent; without a profile URI we have to make the assumption the data is what the publisher meant. > Personally, I dislike GRDDL as long as it keeps ties to XSLT, as XSLT is > a *horrible* way to write RDFizers compared to, say, javascript. [and > it's not for lack of XSLT knowledge that I say so] I don't disagree about XSLT being hard work, but GRDDL isn't formally tied to it. XSLT is only one way of expressing the transformation algorithm. One reason the docs are full of it is convenience - it's an easy fit for the document -process-> RDF kind of pipeline, just give the "process" stylesheet a URI and you're done (another reason was the existing rdf-in-html material using XSLT). As the spec puts it: [[ While technically Javascript, C, or virtually any other programming language may be used to express transformations for GRDDL, XSLT is specifically designed to express XML to XML transformations and has some good safety characteristics. ]] Also note there's nothing to stop an implementation seeing a transformation URI like "http://example.org/wiki2rdf.xsl"; and using Javascript to do an equivalent transformation. > If there was a standardized object model for RDF stores in javascript > (sort of a DOM for RDF), then you could imagine having cross-platform > GRDDL in javascript (and yes, I'm aware that W3C wants to standardize > that), but for now you're stuck with XSLT. I've not spent enough hands-on time with Javascript to know the issues, but a standard js model does seem a very good idea. There would be the bits and pieces around JSON to draw on, and Tabulator's internal model, and I bet the SIMILE work has already covered most angles. Whatever, it would be really good to get some examples of Javascript-based RDFizers used with GRDDL, if you have any thoughts on how best to do this please drop a line to the mailing list. > So, Ben says RDFa is better because more explicit, you say GRDDL is > better because allows you to RDFize even stuff that is not RDF to start > with (like microformats) and I say that scraping is better than GRDDL > because I can use a real programming language and because I don't need > to have any RDF buy-in from the data publisher. Heh, quite. Although I rather like the argument that with GRDDL it means the domain-specific stuff *is* RDF to start with, without publisher buy-in. CustomRdfDialects [2] as Dan Connolly puts it. > But I continue to think that having RDFa data embedded right in the page > could be useful. Assuming the implementation cost isn't excessive, that seems a very good idea. Cheers, Danny. [1] http://microformats.org/discuss/mail/microformats-discuss/2007-February/008880.html [2] http://esw.w3.org/topic/CustomRdfDialects -- http://dannyayers.com _______________________________________________ General mailing list [email protected] http://simile.mit.edu/mailman/listinfo/general
