Re: Thoughts on RDFa from Twitter

On 21 January 2011 02:32, Manu Sporny <msporny@digitalbazaar.com> wrote:
> Some thoughts on RDFa from Twitter. I know that we've covered most of
> this stuff before, but it's still interesting to see how folks that
> opinion in mind as we put the finishing touches on RDFa 1.1 and think
> about how to aid adoption in the future:
>
> nevali: @derivadow SVG+RDFa? ;)
>
> derivadow: @nevali yeah yeah - have added a bit of RDFa to all our pages...
>
> nevali: @derivadow I have *massive* misgivings about RDFa, in truth. I
> think it's a total bust.
>
> nevali: @fantasticlife I'm actually starting to come to that conclusion.
> RDFa exists, people keep mentioning it, but when I say it's broken
> everyone seems to agree?!
>
> derivadow: @nevali yeah i know what you mean - we've only implemented
> the crumbtrail RDFa
>
> manusporny: @nevali @derivadow @fantasticlife So, what's broken with
> RDFa? Would like to know 'cause we're working on RDFa 1.1 right now.
>
> nevali: @manusporny the basic principles of it. the people who know the
> things you need to know to do RDFa aren't the people who make templates.
>
> nevali: @manusporny a bit more detail here — http://neva.li/dIq8Kc
>
> fantasticlife: @manusporny dunno. not heard any complaints. best to ask
> @moustaki tho. he's sprinkling rdfa liberally around /programmes and
> seems happy
>
> fantasticlife: @manusporny and tend to disagree with @nevali's post.
> front end people (& designers & prod managers etc) should know the models...
>
> fantasticlife: @manusporny @nevali ...it's when they don't that things
> blow up :-/
>
> nevali: @fantasticlife @manusporny unfortunately, the reality of real
> web dev work out there disagrees :\
>
> fantasticlife: @nevali @manusporny maybe. i say employ better
> developers. rdfa or no rdfa they'll pay for themselves in the long run :-)
>
> derivadow: @manusporny mostly coz it adds chaff to the page when it can
> more usefully be included in full fat RDF
>
> derivadow: @manusporny it does really solve many problems that aren't
> better solved with RDF
>
> manusporny: @nevali @derivadow @fantasticlife What do you think about
> Drupal 7 including RDFa by default? Are RDFa-aware CMSes a model that works?
>
> nevali: @manusporny only if the RDFa is baked into the code, rather than
> the templates... to be clear, I'm fond if the idea - concerns all practical
>
> fantasticlife: @manusporny again unsure. we don't use cms in my bit of
> world. but past experience makes me think they encourage u to model
> pages not things
>
> -------------------
>
> 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. 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.
> 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.
> 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?
>
> 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. 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>

Thanks for the excellent summary.  I think the simplicity of point (3)
needs to be hammered home, to people that are concerned about
complexity.  Not sure the best route for that.

Looks like some good and specific feedback, though somewhat negative.
There will always be naysayers, the same was true of in the early days
The Web.  It's difficult to draw hard conclusions now, as it was then.

I think the Drupal 7 argument was significant.  Drupal powers 1% of
the web.  The Search Engines will have to start learning to parse
RDFa.  This will hopefully lead to a virtuous cycle of adoption.

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

Received on Friday, 21 January 2011 13:14:27 UTC