Re: Thoughts on RDFa from Twitter

Something I have to add, that I perhaps didn't make clear - RDFa can't 
be a tech which only handles one use case or the other, it has to be 
optimized to handle both cases well.

I believe the message here is that RDFa currently caters very well for 
those with full sem web knowledge, or the time and skill to pull out a 
drupal grade product, or bestbuy grade website. (those who use/need the 
full expressiveness of RDFa)

... and that there's still some optimization to do for the common case 
of the simple web, for the wordpress', the web designers and the copy 
paste web. (those who just want to make a simple set of data machine 
readable in a way that benefits them, for SEO and use by extensions, 
widgets, spiders etc)

Best,

Nathan

Nathan wrote:
> 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 11:21:03 UTC