Re: RDFa and Microformats

Hello Ben

Thank you for your reply

Ben Adida wrote:
> Hi Martin,
>
>   
>> I received an un-inspiring response from the RDFa community,  which
>> surprised me a little because later that month it was part of the
>> Agenda at the following Telecon meeting on the 28th of that month
>> http://www.w3.org/2008/08/28-rdfa-minutes.html#item03. I wish I could
>> be part of those meetings I would have explained further.
>>     
>
> Sorry about that, we're just so swamped that it's hard to keep track of
> everything. 
I understand that...
> Also, the W3C process means that our calls have to follow
> certain rules.

I understand that too...
>  Are you a W3C member by any chance?
>   
No I am afraid not, too much of an expense for me, that's why I tend to 
dedicate most of my time to voluntary communities, One day when I can 
afford the expense :-)
>   
>> You over complicate microformats if you think of it in that way,  they
>> have a very basic parsing model which goes a little something like ....
>>     
>
> From your description (and from our past experience), it already looks
> like there are vocabulary-dependent differences. And that's exactly what
> we made sure to steer clear of in RDFa.
>   

Exactly good for you to notice there is a huge difference...
> If you want to use microformats *exactly* as is, you have to vary your
> parsing rules based on the microformat in question, and the best way to
> do that is, as Toby has mentioned, using GRDDL and @profile. We may
> eventually be able to use @profile to feed the RDFa tools pipeline, but
> not yet.
> What we discussed recently is the possibility of making the prefix story
> simpler for microformats-*like* markup, but still using @rel, @property,
> @typeof consistently. We still need to work on that, but note that we're
> *not* talking about subsuming existing microformats as-is into generic
> RDFa, as that would make RDFa parsing vocabulary-dependent. That would
> break a lot of the goodness of RDFa.
>   
Yes and the goodness of GRDDL, In fact I am beginning to believe that 
Microformats And RDFa are not well suited at all and the whole idea was 
and Interesting but pointless discussion. This I think is because Both 
Microformats and RDFa use GRDDL profiles, One or two GRDDL applications 
Redland, ARC that I know of Parse hCards by default without using a 
transformation link, just using the data-view profile see: 
http://librdf.org/parse?language=grddl&uri=http://weborganics.co.uk/demo/hcard.xhtml,  
so what if I were to mix that with some RDFa, see: 
http://librdf.org/parse?language=grddl&uri=http://weborganics.co.uk/demo/hcard-RDFa.xhtml, 
Triples are repeating themselves but in different contexts, thats not 
exactly a defining "meaning", It only brings myself to ask Why use RDFa 
in my markup when Microformats are easier?
>   
> You know that's what I always thought, but I have been made to believe
> RDFa is a General Purpose Syntax used to describe semantics in XHTML,
> not limited to just RDF,    
> That would be incorrect, as RDFa maps directly to RDF. There may be
> syntactic sugars for certain URLs and vocabularies, but it's always
> triples at the end. What else would it be?
>   
Thank you for confirming That small issue up for me... I never did get 
to the bottom of it, Do you not think RDFa could be used to extract 
Atom, RSS2 or even XSPF, I do , its fairly easy with a little xslt in 
fact I believe that Its actually easier to perform  XSL transformations 
on RDFa because of the "extra" properties and their very precise meanings,
> Maybe you're not quite seeing that RDF is powerful enough to express
> everything, in particular all microformats. Its power comes from its
> generic data model.
>
>   
No I do see that, Using Microformats as an example was probably a bad 
idea, which seems to have caused some confusion....lets just drop it :-)

I will say I dont believe the RDFa Syntax should be limited to RDF when 
it can be so much more, it CAN be a Generic Syntax to Describe 
Semantics, not Limited to RDF...

> IF RDFa is just about RDF then I will leave you all here and never bring
> up this topic again because it is my view Namespaces/prefixes/CURIEs are
> not that well supported in modern browsers, not even well enough  in the
> W3C's own technologies add that to the fact that anyone can create a RDF
> vocabulary without using any kind of process encouraging website
> developers to build walled gardens around themselves in their own
> namespaces and Vocabularies... UGH! anti-social to say the least.
>     
>
> I think you're conflating and possibly confusing a few issues.
>
> First, there's a mistake: CURIEs need not be explicitly supported in
> browsers. We've shown with our implementations [1] that we can easily
> build RDFa parsers in existing browsers using simple JavaScript. So
> there's no significant question of tool support.
>
> Second, the fact that anyone can create a RDF vocabulary is a feature,
> not a bug. The Web is distributed, and there's no reason vocabularies
> should be any different. The granularity of individual fields
> corresponding to URIs makes for loosely coupled applications that are
> vastly more powerful, and the extensibility of vocabularies lets
> publishers add value while remaining compatible with existing tools.
>
> Third, walled gardens and anti-social? I think that has nothing to do
> with the technology and everything to do with what individual publishers
> choose. If they choose to build a walled garden, 
That again is a rant, Mainly at the would be publishers of RDFa, Do you 
really think that commercial publishers are not going to exploit RDFa 
and not build walled gardens and be anti-social? This suggested to me by 
an SEO I know,   The idea is that every website that he builds for his 
clients ARE going to exist in its OWN namespace He believes this will 
Increase the Page Rank of all his sites because the underlying "Meaning" 
is unique to the site.. it goes a bit further that it basically means 
instead of creating one link to a page you can deliver a hundred 
different links in a hundred different contexts because the namespace 
that he creates for each site map to keywords like 
http://somesite.com/ns/wood  or  http://somesite.com/ns/mahogany

> that's their choice,
>   
Ok thats your view...
> but they won't benefit from other tools. There's incentive, in RDFa, to
> use existing vocabularies wherever possible, and extend only when
> necessary. It's in fact, far more social and collaborative, because you
> can benefit from the group while adding your own individual customizations.
>   

And so adding to the Noise that is RDF...
> Now, is there room in RDFa for simplifying markup in simple cases, by,
> for example, declaring a default namespace for an entire DIV? Almost
> certainly. But we don't need to break the generic parsing model of RDFa
> to get there. The generic parsing model of RDFa is one of its big wins,
> in my opinion.
>   
{Noted}
> -Ben
>
> [1] http://www.w3.org/2006/07/SWD/RDFa/implementation-report/
>

Received on Saturday, 13 September 2008 21:19:20 UTC