Re: RDFa and GRDDL and Drupal

On Mon, 2006-05-29 at 21:37 -0400, Ben Adida wrote:
> On May 29, 2006, at 8:48 PM, Dan Connolly wrote:
> 
> > Yes, there are. Lots of them.
> > Please look around before you jump to conclusions and spread
> > misinformation.
> 
> Fair enough, Dan. I apologize for missing this.
> 
> I would like to ask that you be just as careful when you're talking  
> about RDFa. Your last two emails are incomplete and thus incorrect.
>
> Remember the RDFa requirements (a subset here, for clarity):
> 1) publisher independence in picking vocabularies
> 2) in-context metadata with copy-and-paste
> 3) expressing metadata about embedded objects and fragments of pages
> 
> GRDDL doesn't provide (2).

Quite. It's not clear to me that (2) is among Dries Buytaert's
requirements.

>  Microformats don't provide (1) and (3).  
> eRDF doesn't provide (2) and (3).

Yes, (3) is a limitation of eRDF; people seem to be working on
that; see http://www.bnode.org/archives2/58

> I hope that, next time you suggest GRDDL or MFs or eRDF, you point  
> out these three important pieces of information. RDFa was created for  
> a number of important reasons, reasons I've discussed with you in  
> private and on this mailing list many times. Please remember these  
> points in the future, even if you disagree with them. Without  
> pointing them out, you're misleading folks by claiming that they  
> "might as well" use other solutions.

I'm trying to find out what their requirements are.

And "might as well" aren't my words. My words were:

| Perhaps a GRDDL dialect that works without changes at the DTD level 
| would be more straightforward for them to pick up...



> Yes, it's clear you prefer everything but RDFa. But no, these  
> solutions are not all the same. MFs might be enough in some cases.  
> GRDDL might be enough in some cases. eRDF might be enough in some  
> cases.

That's what I'm trying to find out: is this one of those cases?

>  These are all great contributions that have their place. But  
> they are not replacements for RDFa, and there are a *lot* of  
> legitimate uses of RDFa, in particular Creative Commons (50M pages  
> and growing), semantic wikis, etc....
> 
> [...]
> 
> > rel="tag" is certainly simpler than RDFa or eRDF or GRDDL or any
> > of the other markup idioms in this space and it's pretty widely
> > deployed. I don't look forward to trying to change author habits
> > for that sort of thing.
> 
> And yet you too are trying to change authors' habits, by having them  
> add a PROFILE attribute when that is clearly not the current  
> practice. I think it's a great idea, but you can't have your cake and  
> eat it, too. Either you accept what authors are doing exactly as is,  
> or you try to change their habits.

Yes, I included GRDDL in the list of things that are not as simple
as reltag.

>  Clearly, what authors are  
> currently doing is not enough, according to your own efforts.
> 
> I think you and I agree here: there is a problem with scalability if  
> you don't ground your concepts in URIs *somehow*. So, when  
> microformat users start adding a PROFILE attribute, then GRDDL will  
> work, and so will hGRDDL for converting microformats into RDFa, and  
> then all the RDFa tools can read microformats and preserve metadata  
> context, and life will be great! The same can be done for eRDF, with  
> a profile attribute. I want an inclusive approach to all of these  
> things, and this inclusive approach *includes* RDFa for all of the  
> important use cases that are not covered by other solutions.
> 
> I was under the impression you thought this was a cool idea [1].

I'm still ambivalent about RDFa. It addresses copy-and-paste
better than other techniques, but at a cost that I'm not sure
is affordable for a critical mass of authors and tool-builders
and such.

> Regardless, I would ask that you accept that, even if you don't see  
> the point of RDFa, many people do.
> 
> -Ben
> 
> [1] http://dig.csail.mit.edu/breadcrumbs/node/133
-- 
Dan Connolly, W3C http://www.w3.org/People/Connolly/
D3C2 887B 0F92 6005 C541  0875 0F91 96DE 6E52 C29E

Received on Tuesday, 30 May 2006 12:36:34 UTC