226648 - Digital Object Identifiers (DOI) as valid URIs

Status: RESOLVED WONTFIX

(Core :: Networking, enhancement)

Description

[andrew]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007

In the scientific literature, it is becoming more and more common to utilize DOI
numbers to reference persistent internet content. Please read
http://www.plosbiology.org/plosonline/?request=get-document&doi=10.1371%2Fjournal.pbio.0000057
for more information.

There are already hundreds of journals that are using DOIs, and most major
publishers have committed to do so (and are actively using them).

Reproducible: Always

Steps to Reproduce:
1.
2.
3.




http://www.plosbiology.org/plosonline/?request=get-document&doi=10.1371%2Fjournal.pbio.0000057

Comment 1

[Boris Zbarsky [:bzbarsky]]

That article doesn't explain how to actually convert a doi:// URI into something
useful...

Scrounging around, looks like there is a C library (under essentially a BSD
license) that can handle the DOI lookups (or so it claims) at 
http://www.handle.net/HSj/HCL-C-rel-notes.html

Assuming it's OK for us to just use that library, I would guess some glue code
will need to be written to actually hook into it for doi:// URIs.

Comment 2

[andrew]

Oops, so sorry - I confused this article with another that gave much more
technical info... apologies...

Take a look at http://www.doi.org/tools.html - there are a couple Mozilla
plugins/components that others have written that may be good starting points.

The full gory details for implementing DOI lookups is at http://www.doi.org/hb.html.

Cheers,
-Andrew.

Comment 3

[Benjamin Smedberg]

Taking a quick look at the DOI resolution spec it looks fairly complicated, and
I personally that to include this in default builds would be feature bloat.
Looks like a perfect case for an extension...

--BDS

Comment 4

[Malcolm Rowe]

This whole thing looks like a really bad idea. It seems like a 'Not Invented 
Here' rewrite of the entire Web Architecture (the REST and SemWeb models): 
persistent document identifiers (URI's), multiple representations (Accept-
Types), delegated registration and resolution (DNS), to name a few. About the 
only thing that's not in the existing WebArch models is distributed resource 
storage.

Anyway, enough ranting. There's already a Mozilla resolver plug-in at 
http://www.handle.net/resolver/ that can resolve DOI URN's. Given that, why 
would we want to burden Mozilla with handling DOI URN's as a first-class object?

WONTFIX?

Comment 5

[andrew]

Whether or not DOIs resemble other attempts at persistent monikers, these are
the things that seem to have fallen out of the wash. They are already being used
quite extensively in the scientific literature (ISI, Elsiever, ScienceDirect, etc.)

As for making them first-class objects - it kind of depends on your perspective.
A *lot* of science gets communicated via browser, and many (most?) research
articles in journals now include vast amounts of "supplemental material" that is
referenced by http-URL. Being able to resolve DOIs without installing "extra"
software would really be a boon to research.

There really does need to be some sort of persistent 'net-moniker out there. I
won't claim that DOIs are better than any other past solution... but it does
seem like that is what (the scientific) community is gathering around.

Maybe rather than implement the entire spec, do something similar to
http://www.handle.net/resolver/mozilla/ and just recast the DOI URI to a
redirect service? That would remove the issue of bloat...

-A.

Comment 6

[Boris Zbarsky [:bzbarsky]]

Yeah, the redirect thing would be pretty simple to do...
http://www.handle.net/resolver/mozilla/ is basically a JS component implementing
a protocol handler for the doi protocol (see
http://www.handle.net/resolver/mozilla/hdl-0.2.xpi).

It would be quite feasible to check that into the tree provided that:  1) The
sites it uses to proxy are going to stay and 2) There are no licensing issues. 
3) Darin approves.

Comment 7

[Gervase Markham [:gerv]]

We could check it into the tree - but why bother? What do we gain by taking on
more code that someone has to maintain? It's already an extension; and I can
think of a whole load of excellent extensions I'd rather take.

But then, I was only CCed for licensing fu... Rub my lamp again if there turns
out to be any. ;-)

Gerv

Comment 8

[timeless]

fwiw DOI was referenced in today's front section of The Washington Post.

some minor notes in case people are interested in the impl bz referenced:
1. the site needs to be evangelized not to send xpi's as text/plain.
2. install.js should not kill component.reg, that's very rude and can result in
the loss of external components which were registered with mozilla.

3. HDLProtocolHandler.prototype.allowPort =
function (aPort, aScheme) {
    return false;
}

I'm fairly certain that's incorrect. I believe it should say ok for its own
default port.

4. using 'zilla' is taboo, mozilla.org has an agreement with the godzilla people
which allows mozilla.org to use a specific set of zilla's. The module should be
renamed (sorry). Other people using *zilla may be subject to lawsuits.

5. HdlzillaModule.getClassObject:                                              
                     
the behavior for getClassObject(compMgr, randomarg,
Components.interfaces.nsIFactory) appears wrong.

Comment 9

[Christian :Biesinger (don't email me, ping me on IRC)]

>I'm fairly certain that's incorrect. I believe it should say ok for its own
>default port.

only if the uri has a port usually... e.g. consider the data: handler, which
also always returns PR_FALSE

Comment 10

[Gervase Markham [:gerv]]

This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 11

[Christian :Biesinger (don't email me, ping me on IRC)]

.

Comment 12

[Sebastian Busch]

I would like to vote against closing this feature request. I agree that it is more code in firefox, however this is not a surprising point when introducing a new feature. It is also true that such a feature is only of interest for a relatively small group, namely researchers. However, given the high influence of those people on many students, I think it might be a good investment to add a feature they will enjoy.

I am not sure about license issues, but I think all that needs to be done is to add an autocompletion that changes

doi:10.1000/182
into
http://dx.doi.org/10.1000/182

Given the mighty autocompletion tools of firefox to date, this should be a rather easy thing to implement.

Comment 13

[Anne (:annevk)]

This can be done as extension or even by a website using registerProtocolHandler().