W3C home > Mailing lists > Public > semantic-web@w3.org > October 2010

Re: rdfa vs. links

From: Stephen Williams <sdw@lig.net>
Date: Sun, 24 Oct 2010 10:48:02 -0700
Message-ID: <4CC47152.5010303@lig.net>
To: William Waites <ww@styx.org>
CC: semantic-web@w3.org
The best reason I've seen to use RDFa was demonstrated at a W3C plenary meeting at MIT several years ago:
With RDFa, when a user cuts and pastes visible HTML content, they also get the RDFa that is exactly associated with that 
content.  There is a demo of a Javascript page that can receive the paste and display the RDFa nicely.

Hard to see how that would work, especially with a typical web browser engine, with linked RDF information for the page.  For 
user selection, you'd have to have a whole parallel system which, at the limit, would have to reproduce just about what you have 
with a web display engine.

That doesn't mean that all of the related RDF has to be on the page, but at least enough to link semantically to the rest would 
be nice.


On 10/24/10 10:33 AM, William Waites wrote:
> The argument was recently put to me that "rdfa was designed for
> layering rdf into html". While I'm not against the idea of doing
> this (and am happy to get data this way from people who find
> it more convenient to make them available with RDFa) I generally
> prefer to make RDF/XML and N3 available and link to them using
> meta http-equiv.
> So the question is about best practices. I can also layer CSS
> and JavaScript in HTML using<script>  and<style>  tags and in
> some circumstances it might actually be convenient to do so
> but generally I think is better to link to them as separate
> documents. Is this not so also with RDF?
> Cheers,
> -w

Stephen D. Williams sdw@lig.net stephendwilliams@gmail.com LinkedIn: http://sdw.st/in
V:650-450-UNIX (8649) V:866.SDW.UNIX V:703.371.9362 F:703.995.0407
AIM:sdw Skype:StephenDWilliams Yahoo:sdwlignet Resume: http://sdw.st/gres
Personal: http://sdw.st facebook.com/sdwlig twitter.com/scienteer
Received on Sunday, 24 October 2010 17:48:35 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 08:45:20 UTC