Re: RDFa actions in web browsers (UI)

Ben Adida wrote:
> This strikes me as precisely the wrong way to do things. The point about
> expressing structured data is that you want to express structure, and
> then you let the user do whatever they want with it. For example, you
> express an address, and the user may map it on Google Maps, or store it
> in his GIS database, or compare to his address book and see if he has a
> phone number for that address, etc....
> 
> In other words, the actions should *not* be decided by the publisher of
> the data in the first place. Otherwise, what's the point of providing
> interoperable structured data? Tightly coupling data with actions is the
> old web. Loose coupling, where you take structured data and do whatever
> your browser allows you to do with it, that's the data web.
> 
> What do you think?

I definitely agree with that philosophy. :) I'm a very big supporter of
the application deciding how to process semantic data.

Here's why I think that discussion is happening:

Reason #1
---------

It is a philosophical debate, and like most philosophical debates, you
have people on both sides of the debate because there are fundamental
differences in the way each side views the world. This particular
debate has two sides:

  Side A: Publishers should be able to specify UI actions for their
          semantic content in their HTML.

  Side B: The browser should be solely responsible for injecting UI
          into the page?

You and I seem to fall into "Side B", however - there are several good
arguments for "Side A". In talking with both the Firefox and Songbird
folks - they want to give more control over browser behavior to
publishers, and they want to do this in a standards-compliant way.

Most browser writers seem to fall more towards "Side A" because it
allows more experimentation and flexibility. For example, Songbird is
releasing a Javascript API that allows website authors to directly
control some playback and content library management features. Speaking
as a publisher, this is really cool because it allows one to fine-tune
the user experience on your website.

Reason #2
---------

Building a common UI for semantic data is proving far more difficult
than initially expected. For example, if you view the following page
using Operator:

  http://www.ilovejackdaniels.com/cheat-sheets/css-cheat-sheet/

You get no less than 126 contacts and 32 addresses... which is not
easily navigable via a drop-down menu (which is primarily Operator
employs). Granted, it is better than not having access to that data, but
the "drop down menu" approach is not usable on that page.

The question of "How do you notify a user that they are looking at
semantic data without being annoying or distracting?" is quite difficult
to answer when you get down to implementation.

Reason #3
---------

Implementors (including ourselves) are having a very difficult time
mapping semantic data to a common model. If this semantic web stuff is
going to take off, it needs to work well in all browsers with a very
clear implementation path for the formats and the actions in Internet
Explorer, Opera, Konqueror and the numerous other browsers that are
going to be 2nd generation implementors.

Similarly, the browser writers need a common model to map this stuff
to... nobody wants to write parsers AND actions for "hAudio uF", "hAudio
RDFa", and "hAudio eRDF" for every browser. They want a common data
model that applications can map semantic data formats to... For example:

Data format    |   browser agnostic    |  browser/plug-in specific
----------------------------------------------------------------------
hAudio uF     ->                          Web browser displays generic
hAudio RDFa   -> map to 'audio' model ->  audio model and can perform
hAudio eRDF   ->                          actions on audio model.

> PS: That said, if one really wants to use RDFa to do this, then just
> come up with a vocabulary....  :)

They can... but then they have to get everybody to agree to their
"standard" - nobody, including browser the writer, likes to implement
"standards" over and over again. :)

I think we're lucky that the Firefox folks are not creating an RDFa
format for this... it probably wouldn't fix the real problems, anyway.

So what are the real problems? Here are a couple of guesses:

- Nobody has been able to come up with an scalable/elegant way of
  displaying Microformatted content.
- Nobody has been able to propose a unified model for FOAF/hCard
  or any of the other semantic data formats. This leaves the browser
  implementors to write a unified model, which requires a very
  deep understanding of eRDF/RDFa/uF AND each semantic data format.

Ideally the browser writers would have people that would generate
(separately):

- semantic data parsers (uF, RDFa, eRDF)
- a unified data model (browser-specific?)
- a set of actions for each unified data model (browser agnostic?)

Some in the Microformats community, including myself, believe that the
market should sort it out and that browser competition is a good thing.
However, we should also try to minimize upheaval by outlining how we
think this entire ecosystem is going to work or at least give Alex and
Mike some thoughts on what we do/don't want to see.

-- manu

PS: Apologies for the long e-mail. =)

Received on Tuesday, 28 August 2007 17:47:17 UTC