- From: Bradley Allen <bradley.p.allen@gmail.com>
- Date: Tue, 23 Jun 2009 16:47:14 -0700
- To: Kingsley Idehen <kidehen@openlinksw.com>
- Cc: Bill Roberts <bill@swirrl.com>, public-lod@w3.org
I agree that both is better, but there is a catch. As did Toby with his system, in http://t4gm.info, I serve up both XHTML+RDFa and perform content negotiation, generating triples in the MIME type expected by a given RDF-accepting user agent by redirecting the given static XHTML+RDFa page through the RDFa Distiller service. The main issue with this, however, was configuring this in Apache on the hosting provider I use resulted in a solution based on .htaccess that does not respect quality values. I am not currently aware of a working solution to this problem. Doing content negotiation in a completely correct manner presupposes a level of expertise and control over the server side that is not available to everyone who could be fruitfully producing XHTML+RDFa, serving it up with a vanilla HTTP server or embedding it in a hosted blog post. - cheers, BPA Bradley P. Allen http://bradleypallen.org +1 310 951 4300 On Tue, Jun 23, 2009 at 3:31 PM, Kingsley Idehen<kidehen@openlinksw.com> wrote: > Bill Roberts wrote: >> >> Thanks everyone who replied. >> >> It seems that there's a lot of support for the RDFa route in that (perhaps >> not statistically significant) sample of opinion. But to summarise my >> understanding of your various bits of advice: since there aren't currently >> so many applications out there consuming RDF, a good RDF publisher should >> provide as many options as possible. > > Amen! >> >> Therefore rather than deciding for either RDFa or a content-negotiated >> approach, why not do both (and provide a dump file too) > > Exactly! > > RDFa vs Content Negotiation is a misnomer re. Web Architecture :-) > > Kingsley >> >> Cheers >> >> Bill >> >> >> >> > > > -- > > > Regards, > > Kingsley Idehen Weblog: http://www.openlinksw.com/blog/~kidehen > President & CEO OpenLink Software Web: http://www.openlinksw.com > > > > > >
Received on Tuesday, 23 June 2009 23:47:56 UTC