Re: Thoughts on RDFa from Twitter

Manu Sporny wrote:
> 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.

I have to agree here sadly, the thought of RDFa in wordpress (where 
typically HTML and templates are in the domain of junior designers and 
"seo experts") is a bit of a worry..

> fantasticlife: @manusporny and tend to disagree with @nevali's post.
> front end people (& designers & prod managers etc) should know the models...

And I agree here, but we have to make distinctions between classes of 
"front end people" those working for the likes of bestbuy are very 
different from somebody knocking out free templates for a CMS to get 
some exposure - this is the main reason OpenGraph took off so quickly, 
it's just c+p a chunk of HTML in to your template and inject a couple of 
variables.

> fantasticlife: @nevali @manusporny maybe. i say employ better
> developers. rdfa or no rdfa they'll pay for themselves in the long run :-)

obviously one has to agree with this too, but also get some mental 
indication as to how many of the pages of the web are created by 
"employed developers" (also remembering we're primarily talking about 
"web designers" not "web developers") - I'd put it at <50%.

> manusporny: @nevali @derivadow @fantasticlife What do you think about
> Drupal 7 including RDFa by default? Are RDFa-aware CMSes a model that works?

Drupal 7 is in a class of it's own in that respect, and hence why it's 
been possible - it's used by experienced web shops and has a strong 
community of industry professionals, the other CMSs are targeted at 
anybody from your mother to the guy that made an animated gif and is now 
a web master - it's that class which is the problem (and larger), not 
the Drupal 7s of this world.

> 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

agree.

> 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

both @nevali and @fantasticlife are correct here, they're just speaking 
of different sectors and target markets.

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

RDF/XML was confusing and embedded in an already confusing XML stack, in 
addition many people don't "get" conneg - that isn't a recipe for 
success. I'm not sure that is has anything to do with people not wanting 
"to serve up two different types of pages".

Many people still have a similar opinion of RDFa, it's a bit confusing 
and has that XML heritage (via XHTML and xmlns) - conjure up the words 
RDF and XML in somebodies brain and they will relate to RDF/XML - and 
it's a shame that many see it as having this heritage, rather than being 
the tech that adds the missing descriptive markup features to HTML that 
it so badly needs. (People have accepted and adopted CSS, Canvas, Video 
etc because they are seen as adding to the presentation markup of 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).

You can't please everybody, and there are different audiences and 
use-cases for each approach - however, complexity is sure to kill either.

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

A very valid assertion IMHO, but I fear cookbooks and live editors won't 
cut it, facebook and good relations have already shown the successful 
recipe here (for the common case) - a chunk of HTML that you copy, paste 
and fill with variables, specifically focussed around one specific set 
of properties, and covering one specific use case. One could almost 
terms it a "data widget" approach.

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

Sorry Manu but this isn't an idea, it's a reality - data, the domain 
model, and matching it up to open vocabularies is clearly in the domain 
of the developer in most common cases. The heritage and skillset needed 
is entirely different between developers and designers, HTML is the 
convergence point where both meet - a person who does Photoshop -> HTML 
-> a bit of CSS and jQuery typically has neither the skillset, the 
inclination or the understanding to handle the domain model and 
conceptual scheme of the data-tier, the developer on the other hand..

Typical web agency flow is to have the developers working on data and 
systems, the designers working on proofs, visuals and templates - then 
the developers populate with variables and "make it work", and the 
designers do a final pass to clean up the output - the only way for 
typical agencies to get RDFa done is to have the developers bake it in 
to the code, it is after all, there domain model.

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

All true, but RDFa is done in such a way that it's in the domain of the 
skilled developer who can work out RDF, find some vocabularies, and 
match it up to their app specific domain model - and it sits at the 
intersection of the skillsets, where developers don't want designers 
touching their code/data, and designers don't want developers tampering 
with their templates and presentational markup - hence why the snippet 
approach of OpenGraph and GR works out so well in the common case, and 
why "full-rdfa" is typically adopted by larger corporate entities with 
the time and skills needed to do it properly / fully utilize the RDFa 
provided descriptive markup set.

Best,

Nathan

Received on Friday, 21 January 2011 10:33:02 UTC