Re: RDF-EASE: RDFa in CSS

Replying to a few messages in one...

On 31 Dec 2008, at 14:04, Ivan Herman wrote:

> my superficial reading of the draft suggests me that Rease is  
> defined in
> terms of RDFa.

It is. Taking advantage of the RDFa task force's work seemed a  
sensible shortcut.

> Ie, conceptually, an XHTML+Rease document (or even
> XHTML+RDFa+Rease document) is transformed into XHTML+RDFa. Actually, a
> way of implementing it (my RDFa implementor's mind starts working:-)
> would be to add a pre-processor (like the hGRDDL idea of Ben) to an  
> RDFa
> processor and let the trickier aspects of RDFa be solved by an  
> existing
> processor.
>
> Toby, is this the idea? If not, I believe it should be:-)

Very much so. The current parsing algorithm in the draft has as it's  
last step "The document is processed to produce triples, as described  
in §5. Processing Model of [RDFA]." (Though it reference's the RDFa  
Proposed Recommendation rather than the final RDFa Recommendation at  
the moment. I'll reference the final Recommendation in the next  
update to RDF-EASE.)

The current parsing algorithm is not very efficient though, nor  
especially tidy. I plan on writing a replacement algorithm which will  
instead interleave RDF-EASE steps inside the RDFa algorithm. This  
would reduce the number of passes over the DOM tree.

There is, by the way, a mostly working partial implementation here:

http://buzzword.org.uk/2008/rdf-ease/implementation-20081224.pl

This does RDF-EASE to RDFa, but doesn't go as far as producing an RDF/ 
XML file from the RDFa.

> I have one technical comment, though. The CSS Working group has  
> already
> published a CSS3 Namespace Module:
>
> http://www.w3.org/TR/css3-namespace/
>
> which uses a slightly different syntax than Rease for a similar  
> concept.
> I think it would be way better to align Rease to this. One could  
> expect
> that CSS parsers of the future would include this namespace facility,
> which might greatly facilitate the task of Rease implementers...

I had originally planned to use an @rule for defining CURIE prefixes,  
but the Perl CSS parser (which I've used for my test implementation)  
chokes on it, which is one reason I chose a slightly odd method. Long  
term, a deficiency in one particular parser is a poor reason to  
influence the design of the spec, so I think an @rule should be  
preferred.

I'm not sure about using @namespace though. There have already been  
some people saying that reusing XML namespaces for CURIE definitions  
in RDFa might have been a mistake (e.g. it's problematic for DTD- 
based validation; it makes porting RDFa to non-XML SGML harder), and  
that it may have been better to define a different method of marking  
up CURIE prefixes. Perhaps RDF-EASE should use '@prefix dc "http:// 
purl.org/dc/terms/";' ?

Dan Brickley wrote:

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


I think you might have suggested this to me before. My XSLT skills  
would be nowhere near adequate for such a task - wouldn't even know  
where to start. But it certainly seems an interesting idea.

Giovanni Tummarello wrote:

> If that's the case, then RDFa suffices as that and i'd be scared to
> propose yet another RDF serialization mechanism.

In a way, it's not another RDF serialisation mechanism. There are  
really two W3C-approved solutions for embedding RDF triples in XHTML:  
RDFa and GRDDL. GRDDL is open-ended though. GRDDL is incredibly open- 
ended though, even by usual W3C standards - it allows for  
transformations to be written in any programming language. (It  
doesn't even especially recommend any particular programming  
languages, though it notes that XSLT, especially XSLT1, is well- 
supported by existing GRDDL implementations.) RDF-EASE simply defines  
another programming language which may be used - a very simple, non- 
Turing-complete one.

I'm a big fan of RDFa, but I realise that a global switch to RDFa is  
not going to happen overnight - people will be using Microformats,  
and creating their own informal microformat-like patterns of classes  
to mark up their documents, for a long time yet. RDF-EASE just  
provides them with the easiest way that I can think of to map those  
patterns to RDF triples.

Even for people who would normally write RDFa, RDF-EASE provides some  
big reductions in key-strokes. To mark up a simple list of names and  
e-mail addresses in RDFa takes a lot of work:

	<ul>
	  <li typeof="foaf:Person">
	    <a rel="foaf:mbox" property="foaf:name"
	       href="mailto:alice@example.net">Alice</a>		
	  </li>
	  <li typeof="foaf:Person">
	    <a rel="foaf:mbox" property="foaf:name"
	       href="mailto:bob@example.net">Bob</a>		
	  </li>
	  <li typeof="foaf:Person">
	    <a rel="foaf:mbox" property="foaf:name"
	       href="mailto:carol@example.net">Carol</a>		
	  </li>
	</ul>

Whereas with RDF-EASE you'd get:

	<ul class="people">
	  <li><a href="mailto:alice@example.net">Alice</a></li>
	  <li><a href="mailto:bob@example.net">Bob</a></li>
	  <li><a href="mailto:carol@example.net">Carol</a></li>
	</ul>

And:

	ul.people li {
	  -rdf-typeof: "foaf:Person";
	}
	ul.people li a {
	  -rdf-property: "foaf:name";
	  -rdf-rel: "foaf:mbox";
	}

And if you decided to switch from, say, FOAF to the vCard ontology,  
then the HTML wouldn't need to change - just the transformation.

For these reasons, people might find it beneficial to author using  
XHTML + RDF-EASE and publish plain old RDFa, performing the  
transformation server-side.

-- 
Toby A Inkster
<mailto:mail@tobyinkster.co.uk>
<http://tobyinkster.co.uk>

Received on Wednesday, 31 December 2008 18:11:55 UTC