Re: RDFa actions in web browsers (UI)

Hi Manu,

I found this discussion very interesting, since it's actually been the
area I've been working on for a while now. I started penning a reply
but it got too big, so I ended up creating a blog entry called
'Sidewinder and the need for a semantic web applications framework'
[1].

Not all of is relevant to this discussion, but I think the part that
is, is the use of a binding language in a manner similar to
stylesheets:

  The third problem--the use of binding rules to indicate which widget should be
  connected to what data--is still a little in the air. One part of it
we've solved by
  specifying binding 'rules' using XPath selectors that are data type
aware [2]. This
  means that we can indicate that data of type 'geo location' should
have one set of
  behaviour bound to it, whilst data of type 'time' can have a
different type. These
  are essentially binding stylesheets and I think this is where we can
answer the
  question posed on the RDFa list as to whether it is the author, the
end-user or the
  browser vendor that should be in control of the widgets--the answer
is all of them!
  By allowing users to express binding rules that override those from
authors, we
  can achieve the best of both worlds.

Although it's out of scope for our immediate priorities with RDFa, it
is certainly going to be something we'll have to solve at some point
in the future, so it's good to see discussion on this.

Regards,

Mark

[1] http://internet-apps.blogspot.com/2007/08/sidewinder-and-need-for-semantic-web.html
[2] http://www.formsplayer.com/node/884

-- 
  Mark Birbeck, formsPlayer

  mark.birbeck@formsPlayer.com | +44 (0) 20 7689 9232
  http://www.formsPlayer.com | http://internet-apps.blogspot.com

  standards. innovation.

On 28/08/07, Manu Sporny <msporny@digitalbazaar.com> wrote:
>
> 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 20:52:02 UTC