Dan Brickley (he of FOAF fame) has posted a few replies in the RDF-EASE thread on this mailing list. He writes:
Another thought (hmm maybe I mentioned this before) - does the idea of an RDF-EASE-to-XSLT convertor make sense, so that EASE could effectively serve as an authoring tool for GRDDL XSLT documents?
This sounds like a good idea to me. XSLT is supposedly Turing-complete, and RDF-EASE is less than Turing-complete, so it should be theoretically possible. Just so long as I don't have to write it!
In another message Dan writes:
BTW, thinking about RDF-EASE a bit more, I've been wondering whether it could serve as a nice abstraction layer for writing screenscrapers in general. […]
Does anyone here care to try writing RDF-EASE for Myspace, Last.fm, BBC Music or Wikipedia music entries? If that turns out well, the next piece of the puzzle is discovery/applicability: figuring out which RDF-EASE documents are usefully applied to which pages.
BBC Music already has RDF/XML, but the general idea is good. RDF-EASE is based on GRDDL, which does allow for behaviour like this — that is, it allows for parsers to apply transformations to pages even when the page doesn't explicitly link to the page. Parsers could use a third-party service to determine which RDF-EASE transformations are appropriate for a page.
Meitar Moscovitz on SitePoint
In Add Semantic Richness To Your Markup With (RDF) Ease Meitar Moscovitz is generally positive about RDF-EASE but has some concerns.
While “more semantics as a good thing” is not being challenged, RDF-EASE does introduce a conceptually problematic notion for me: it moves the semantics of a document further away from the content itself.
I would counter that RDF-EASE does not move semantics out of the document, but instead formalises semantics already present. Plenty of documents already contain constructions like:
<table class="staff-list">
<tr>
<td class="name">Joe Bloggs</td>
<td class="location">Paris</td>
</tr>
<!-- … -->
</table>
The semantics are already there. RDF-EASE (and GRDDL more generally) simply provides a way for software agents to interpret existing semantics in documents:
.staff-list tr { -rdf-typeof: "foaf:Person" }
.staff-list tr td.name { -rdf-property: "foaf:name" }
.staff-list tr td.location { -rdf-property: "foaf:based_near" }
While I am a big fan of RDFa, RDF-EASE provides an alternative route to RDF for people unable or unwilling to use RDFa. It can be applied to documents generated by legacy databases and content management systems that are unable to support RDFa. It can be applied to documents in environments where conformance to a particular non-RDFa (X)HTML DOCTYPE is mandatory.
Some existing RDFa publishers might even be tempted to mix RDFa and RDF-EASE (which is why the draft makes it very clear how they interact) for conciseness. For example, the staff list above would require many repeated typeof="foaf:Person" attributes, which are handled with a single selector and rule in RDF-EASE. Scripts could be used to transform the RDFa+RDF-EASE to pure RDFa as part of the publishing process.
Karl Dubost in a Comment on SitePoint
Karl wrote:
It looks very similar in the idea to cow which was an attempt at creating a semantic structure with a very simple syntax but outside of the document.
I certainly didn't mean to imply that I was the first person to investigate this area, as I know for a fact that I am not. I do however, think that RDF-EASE is the best suggestion so far for RDF in CSS. Strangely I hadn't seen COW (Cascading Ontologies for Web v. 0.1) in my research into previous attempts at RDF in CSS. COW does not seem to be particularly RDF-like, and the specification appears to be a very early draft, not clearly demonstrating how it should be used — it isn't really clear what these key things are in it. COW is perhaps more similar to encoding the XHTML role attribute in CSS (and in fact, early versions of RDF-EASE allowed for @role too).
My main comparison point when drafting RDF-EASE was A comparison of the inline RDFa format to a hypothetical Cascading-RDF format, which offers a less CSS-like syntax than RDF-EASE. It reuses CSS's @namespace keyword, but with a different syntax from CSS. From the examples appears to make it very tricky to mix RDF vocabularies. It is not entirely clear how some RDFa constructs could be replaced by cRDF.
Shelley Powers on burningbird.net
Shelley wrote
(look, I'm linking to her — three times if you count @cite!):
Frankly, RDF-EASE is an awful solution. […]
Ouch! You know, words can hurt too Shelley.
[…] It's an example of how extreme we can go in order to provide some way of documenting RDF in HTML5 because the HTML5 folks are too intransigence in their rejection of any form of RDF.
I don't know if I count as an "HTML5 folk". I follow the WHATWG and HTMLWG mailing lists closely and occasionally post to them. I am not known for my rejection of any form of RDF and would positively love to see RDFa adopted into HTML5.
The idea of a CSS-based form of RDF was touted on the WHATWG list back in August 2008 as a possible way to satisfy those wanting a mechanism for embedding RDF in HTML5. My initial reaction to this was that it sounded like an awful idea. But I wasn't exactly sure how just how awful it would be — I wanted to quantify its awfulness. And so I started RDF-EASE, looking for the best possible solution to RDF-in-CSS. (Initially it wasn't called RDF-EASE, but RDFARSE, however I couldn't think what the second "R" would stand for, so decided to change the acronym.)
The technique which emerged is not perfect, but when judged within the restraints I set myself (CSS-like syntax, must validate against XHTML 1.0 Strict, reuse existing standards, invent as little as possible) is far, far less awful than it could be. No, it's not as good as RDFa, but in the process of working on it, I think I've hit upon something that's a better transformation language for GRDDL than XSLT is.
