[Rdap] DOIs for research data in DSpace

John Graybeal jgraybeal at ucsd.edu
Mon Oct 1 13:29:50 EDT 2012


Thanks for the Simons reference.  Some thoughts:

There is an analogous puzzle in the semantic world, where the URI identifies a concept, but often also gets repurposed to provide the definition of the concept in OWL, and/or a page describing the concept. I support that on the basis that it increases usability -- if the core functionality isn't obstructed.

Since a DOI in and of itself is not resolvable, the idea that their DOIs can 'allow for direct data download' is not possible on its face. It is the resolver for the DOI that provides resolvability. So it is the resolver that could allow for direct data file download. There are 3 mechanisms that could allow that: (1) Assigning a DOI that is uniquely resulting in a download. (2) Adding a suffix to a resolvable DOI to indicate a download request (or event a type) -- we do this in our semantic repository, it works pretty well. Example: http://dx.doi.org/10.1594/PANGAEA.726855?action=download.  (3) Create a 'download' resolver that tries to initiate the download based on what it can find in the DOI landing page.

Any of these would require modifying existing DOI resolver code to support it, I suspect. And any of them will require that it be possible to update the data set URL in the resolver, for those occasions when the URL has to change.

The next level you'd immediately have to think about is what it means to download the data set. Does the user always know the format and content of the resulting file? Will they never want the data in a different format?  A shame if you had to generate different DOIs for different formats....

The case that is not addressed by the reference [1] is that of citing live bitstreams (as opposed to a static query result. The wording of your query indicates the DOI is is *not* for the live bitstream, so I've not addressed that possibility directly. But this needs to be a citable resource, just as the New York Times newspaper needs to be citable as a publication, even though new supplements come out every day (and there are new editions throughout a day). We will almost certainly do this for Ocean Observatories Initiative -- but just the DOI won't get you to a live stream directly, it will need to give you information about the live stream.

John



On Oct 1, 2012, at 09:30, Konkiel, Stacy Rose wrote:

> Hello everyone,
>  
> We’ve got a research group here at Indiana University that is interested in registering their bitstream (data file) URLs for DOIs for each dataset in their project that’s been uploaded to our institutional repository.
>  
> They point out that a PURL already exists for the metadata page/item record—that’s the DSpace Handle. They want their DOIs to allow for direct data file download. Our IR team is a bit hesitant to endorse this, as bitstream URLs are somewhat less stable that Handles, and DOIs (registered to IRs, SRs, and publishers alike) seem to always point to a landing page of some sort.
>  
> Has anyone dealt with this issue before? I’m familiar with the ANDS/Griffith U example [1] but would like to know more about best practices at other institutions, and the arguments for/against registering bitstream URLs for DOIs.
>  
> Many thanks in advance.
>  
>  
> Best,
> Stacy Konkiel
> E-Science Librarian
> Indiana University
> skonkiel at indiana.edu
>  
>  
> [1] http://www.dlib.org/dlib/may12/simons/05simons.html
>  
>  
> _______________________________________________
> Rdap mailing list
> Rdap at mail.asis.org
> http://mail.asis.org/mailman/listinfo/rdap


----------------
John Graybeal    <mailto:jgraybeal at ucsd.edu>     phone: 858-534-2162
Product Manager
Ocean Observatories Initiative Cyberinfrastructure Project: http://ci.oceanobservatories.org
Marine Metadata Interoperability Project: http://marinemetadata.org







-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kunverj.com/pipermail/rdap/attachments/20121001/749e0eec/attachment-0001.html>


More information about the RDAP mailing list