Re: RDFa and Microformats

Hello Toby..

Toby A Inkster wrote:
> On 15 Sep 2008, at 16:17, Martin McEvoy wrote:
>
>> Talking of  "hacks" why is this NOT a "hack" : 
>> http://wiki.digitalbazaar.com/en/HAudio_RDFa? it looks like a direct 
>> rip from the Microformats wiki,
>
> That article is published by the same Manu Sporny who is editor of the 
> hAudio spec. 
:-)  I know that, its not about Manu I am Talking about the Document 
itself, It in NO way matches the way I think hAudio should be parsed as 
RDF, does that matter do you think?
> (At least I assume it's the same Manu Sporny. Manu Sporny has, I 
> think, a name like mine, in that it can be considered an "inverse 
> functional property".)
>> Old News I'm afraid Microformats do have a generic parsing model just 
>> because you cant read it on a page somewhere , again this is Work in 
>> progress by many members of the Microformats Comunity,  Brian Suda, 
>> Ben West, Myself are some of the people who spring to mind who are 
>> actively working this Problem. more notably  Toby Inkster with this 
>> page http://microformats.org/wiki/parsing-brainstorming ..
>
> If you read the blurb at the top, you'll see that the page covers 
> parsing a good deal of microformat properties, but not 100%. For 
> example, hCard N optimisation, the "tel" and "email" properties for 
> hCard, "item" in hAudio, lots of crazy stuff in hResume regarding 
> intermingling hCards and hCalendar for experience and education 
> properties. (And that last one, I don't think there's any fool-proof 
> way of handling - the hResume spec itself is way too fuzzy.) These are 
> all outside my parsing algorithm.
Parsing Microformats is work in progress (it may never end)  what is 
helping is that all current Microformats in general have their names 
defined in hCard  this helps consistency along with the current 
Microformat design patterns, hResume on the other hand  is a terrible 
format that needs a lot of work, the include pattern is nasty even I 
would agree is a "hack"...
>
> Even if you ignore those issues, the parsing mechanism is still far 
> from generic in the same way RDFa is. If you look at part 4 of the 
> document you cited, step 5.3.1, you will see that the parser needs to 
> "find the value of element e". To do this, it needs to choose one of 
> five different parsing methods. To know which method, it needs to know 
> what "type" of property it is parsing: a plain text string, a 
> datetime, a URL, etc. This requires special knowledge of each property 
> - e.g. the parser needs to know that "fn" should be parsed as a 
> string, but "photo" as a URL. Also, in step 3 it needs to know which 
> properties may contain an embedded microformat. (e.g. an hCard may be 
> embedded in hCalendar's "attendee" property.)
I see your point Toby, there Is no reason why RDFa cant easily become 
microformats aware not all microformats just the ones that use the 
<abbr> design pattern. Im not talking about Boiling the Oceans here, 
only a few classes, less than the html rel support..
>
>
> This contrasts markedly with RDFa which can be parsed without special 
> knowledge of any particular terms (except for a handful of unprefixed 
> rel values which are grandfathered in, mostly from HTML4/XHTML1 - and 
> the special handling they get is only very slightly special).
all I am proposing is that a handful of Microformats just the ones that 
support ISO date times get a little "special" handling, that's not so 
bad is it?

Best Wishes

Martin McEvoy

Received on Monday, 15 September 2008 17:34:55 UTC