Re: Thoughts on RDFa from Twitter

On Jan 21, 2011, at 02:32 , Manu Sporny wrote:

[snip]

> 
> -------------------
> 
> Here are the things that I took away from this chat:
> 
> 1. There is still this general belief that RDFa doesn't do anything
>   more than what RDF/XML did.

It depends how you look at it:-) In _some_ sense, that is correct, insofar as RDFa is _just_ a serialization of RDF from an RDF point of view, just like RDF/XML is...

> People don't seem to understand that
>   RDF/XML was not adopted over the past 10 years because people
>   didn't want to serve up two different types of pages. Now that
>   they can mix data and display, even though it's messy, people are
>   finally publishing data in their HTML.

Let us be more precise. RDF/XML and Turtle has major adoption on its own right, eg, on the Linked Data or eGov side. RDFa does not aim at replacing those. But for some application having, or extracting, separate files is indeed an issue and that is one area where RDFa steps in. For applications that need the RDF data as part of the browser operation, RDFa gives a good solution. Etc.

(Let us not bash on non-RDFa:-)

> 2. Some people seem to be against the idea of mixing data and display,
>   even though when presented with the option to separate data from
>   display (RDF/XML or JSON), people don't take it. It's as if
>   people are arguing for a clean solution (RDF/XML, TURTLE, N3, etc.),
>   but once that solution is presented to them, they're annoyed that
>   it's more complicated than the dirty solution (RDFa).
> 3. There is an assertion that the people that make website templates
>   are not the people that understand RDFa. Don't know if that's
>   true in general or not, but it's worth thinking about this more
>   deeply - and is a good argument for the RDFa Cookbook and live
>   RDFa editors.

Agreed.

> 4. An idea that RDFa should be baked into the code rather than
>   the templates. This goes counter to what the community has been
>   advising - wondering why this approach is being floated as an
>   option?

I am not sure what that means, to be honest.

> 
> In general, the chat demonstrates what many of us know already - we have
> a very long road ahead explaining to web designers why certain design
> decisions for RDFa were made:
> 
> 1. History taught us that separating data from display, while
>   "pure" in design, failed to convince people to publish their data.
>   We've had 10 years of RDF/XML, with very minor uptake.

I do not agree with 'minor'. Let us not develop a messaging around this...


Ivan

> Mostly because
>   there was no benefit for publishing RDF/XML - Google/Yahoo didn't
>   index it because nobody was publishing it. Nobody would publish it
>   because Google/Yahoo wasn't indexing it. Catch-22.
> 2. There are already plenty of options for expressing data separately
>   from the page - in general, only the semantic experts use this
>   technology. We didn't need another separate data format.
> 3. RDFa allows one to modify page templates very little to transform
>   a templated website into a semantically enabled website. Got a
>   <span class="name"></span> field in your template? Make it semantic
>   by adding one property (and one @about statement in the surrounding
>   paragraph tag):
>   <span class="name" property="foaf:name"></span>
> 
> -- manu
> 
> -- 
> Manu Sporny (skype: msporny, twitter: manusporny)
> President/CEO - Digital Bazaar, Inc.
> blog: Linked Data in JSON
> http://digitalbazaar.com/2010/10/30/json-ld/
> 


----
Ivan Herman, W3C Semantic Web Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
PGP Key: http://www.ivan-herman.net/pgpkey.html
FOAF: http://www.ivan-herman.net/foaf.rdf