Re: Microformats and Semantic structure (Part 2)

Hi Charles,

Interesting comments.

> Well, it is the idea behind the recently announced "ARIA" work from WAI.
> UBAccess and IBM were both working on this last century (probably along
> with others), which might be why they are leading the work today. And yes,
> it is an exciting idea, and it is heavily based in RDF.

The WAI work leverages just one of the many hooks that have been
placed into XHTML 2 to allow richer metadata to be added. Some of
these features are being made available as XHTML Modularisation
modules so that they can be used with langauges based on XHTML 1.1. In
this particular case, the 'hook' WAI is using is the @role attribute,
but there are many other features in the RDFa toolkit that can be used
for exactly the things you are describing.


> > The statement "...<div class="paragraph"> does not equal <p>..." still
> > stands!
>
> Strongly agreed.

This is a very interesting point. I think the key thing here is to
differentiate between the semantics associated with the *purpose* of
some mark-up in terms of the document structure (footer, header, main
menu, etc.) and the semantics associated with the *content*  of the
document. The RDFa extensions for XHTML 2 (which as I said, are now
being made available for XHTML 1.1) allow both of these areas to be
addressed.

The 'purpose' aspect is addressed by the already mentioned role
attribute. Obviously we're not saying that every element becomes a div
with a @role:

  <div role="paragraph"> ... </div>

But equally, we can't say that every time you need a new feature like
headers and footers you have to wait for the W3C to update the HTML
family of standards. The balance is therefore struck by having a core
langauge that provides as full a list of elements as possible to
describe the structure of a document (section, h1, h2, div, p, and so
on), and then to provide an additional mechanism to add other
'elements' as needed. This is achieved by @role, which allows you to
do things like this:

  <ul role="menu">
    <li><a href="...">Home</a></li>
    <li><a href="...">...</a></li>
    <li><a href="...">About</a></li>
  </ul>

Now assistive technologies can find their way around the document,
based on semantics about the *structure*.

When it comes to the 'content' aspect though, things are not so easy;
having mark-up in the language that blurs the distinction between the
meaning of the content and its structure (like <address>), has never
really been successful, and tends to confuse. In this context the
approach taken in XHTML 2 is not to add more elements, but to leverage
the use of <meta>, <link>, @class, @rel and @rev, to provide a
systematic and coherent way to add *any* metadata to an XHTML
document.


> There is a potential problem with microformats. While they are a simple
> "poor man's semantic web" that anyone can do, they end up keeping you
> poor. There is no decentralisation process, no formal schema, that can a
> priori disambiguate the use of "date" ('things given', in italian) from
> "date" (the boy or girl we are proposing you go meet). If we assume that
> everyone will make the same use of a free text naming scheme, 2500 years
> of experience suggests we should look more carefully at what we have in
> our pipe and think again. Even with the (in my opinion naive to the point
> of incredibly stupid) assumption that people will always use english in
> the value space.
>
> The greater their success, the more they may doom us to moving on from
> HTML as we love it, unless there is a strict use of the profile attribute
> (or analgous mechanism) to clearly disambiguate and allow validation and
> an out-of-band but automatically processable formal definition of the
> grammar and semantics of a given microformat (or a total centralisation of
> the allowable values of the class attribute) - just the sort of thing that
> simple stuff like microformats starts out trying to avoid. Making the
> decision whether we have gone below the threshold of "as simple as
> possible *but no simpler*" is never easy, but it is not clear to me that
> microformats gets it quite right enough.
>
> Still. The above involves a bit of crystal-ball gazing, and could well
> turn out to be incorrect, since human history and logic are only sometime
> bedfellows, and since there are always assumptions that may prove to have
> been ill-founded.

You are absolutely spot on! The issues you raise are very real:

  * Microformats gets into real trouble when you try to combine more than
    one 'format' (in fact, rules of combination have to be defined);

  * it requires converting already existing langauges so that they work within
    the microformat rules--painful and slow, given that langauges like FoaF have
    already had an enormous amount of work put into them, and this must be
    almost completely repeated;

  * there is no notion of namespacing;

  * adding new languages seems to be based on a few key individuals;

  * there is no way to validate;

  * and it isn't actually a "poor man's semantic web", since it isn't providing
    a generic mechanism, but a way of hand-crafting a small number of
    use-cases--which means that format-specific process still have to be
    created to work out what some mark-up means.

RDFa tackles all of these issues by providing a series of *general*
rules that can be applied to any metadata, rather than the specific
rules for specific formats. It also allows QNames to be used if
required, to resolve the namespacing issue that you flagged up.

Of course it's not an either/or situation, and microformats will
continue to find plenty of uses. But for a solution that can:

  * be written as simply as microformats;

  * scale to any level of complexity;

  * make use of any RDF taxonomy;

  * operates at the level of document *structure* semantics, as well as
    and document *content* semantics

RDFa definitely has more 'legs'.

Regards,

Mark

-- 
Mark Birbeck
CEO
x-port.net Ltd.

e: Mark.Birbeck@x-port.net
t: +44 (0) 20 7689 9232
w: http://www.formsPlayer.com/
b: http://internet-apps.blogspot.com/

Download our XForms processor from
http://www.formsPlayer.com/

Received on Thursday, 12 October 2006 12:39:25 UTC