Re: feasibility; purl.org/commons

Matthias Samwald wrote:
> Yes, with most current web-browsers (those that are not aware of the
> embedded RDF), this could require users to make two clicks instead of
> one.

I do have the Firefox Operator plug-in installed, but I don't quite 
understand how this would allow me to skip the intermediary page? For 
example, when I open http://whatizit.neurocommons.org/template_303.htm, 
Operator detects the list of formats, but that's about it [see menu.png]!


> However, it might turn out that users could be willing to make this
> additional click, when *significant additional value* is associated with
> this intermediate page, or when it generally leads to content of high
> quality.
> An example are those pages that sometimes pop up when you try to read an
> open access article and let you choose between Pubmed Central and Biomed
> Central. I always click on Biomed Central and actually don't really need
> to make that choice all the time, but somehow I have a positive
> associations with these web pages. They force me to do an additional
> click, but in 100% of the cases they lead to a useful, working full-text
> of the article I wanted. 

If you were reading such articles all day long, perhaps you would mind: I'd 
certainly be quite annoyed if when I clicked on a search result in Google, 
I always got an intermediary page that asked me if I wanted to open the 
version in Google's cache, or the original :-)

Being able to get a list different representations is of course useful; I'm 
just not sure if it's a good idea to use such pages as default targets...

If you look at <http://beta.uniprot.org/uniprot/P05067#section_x-ref> you 
can see that we made some links configurable, e.g. you can choose the 
default target for nucleotide sequences to be either EMBL, GenBank or DDBJ. 
Once you make a choice this is remembered until you change it. This seems 
to be an acceptable solution from a usability point of view, but of course 
I'd prefer a more standard mechanism for this kind of thing.


> Of course such a page would list all the available formats (and ONLY the
> available formats).

How are you going to get this information? Would it help if you could do a 
HEAD request to a server and extract and parse an Accept header on-the-fly, 
or would you prefer to bulk-preload such information?