Add URL to Journal article record?

[GoogleCodeExporter]

This is more a request than a problem.  It would be handy to have a field
for a url to link to the article/work. This would make it more valuable as
a publications list.

Jack Ammerman
Boston University
jwa@bu.edu

Original issue reported on code.google.com by jwaCo...@gmail.com on 11 Jun 2009 at 5:27

[GoogleCodeExporter]

Jack,

I'm trying to get a better sense of what you mean by having a "url field".  We
already do this in a few senses with the latest BibApp code (which is 
downloadable
via Subversion).

(1) If you take a look at a person's page on our Demo site:
http://www.library.illinois.edu/bibapp/people/1
You'll notice a "Find It" link which uses OpenURL to search your local Library 
for a
downloadable copy of that article (if its available in one of your local Library
databases).

(2) We are working on taking in persistent URLs (like a DOI - Digital Object
Identifier) during the import process.  This doesn't quite work yet, but it's 
on our
to-do list.  Therefore if a DOI was found during the import, that would become a
clickable link for that work.

(3) If you install BibApp locally with the SWORD plugin enabled, it allows 
BibApp to
deposit content + metadata in your local repository (e.g. DSpace, Fedora, 
EPrints,
etc.).  In this case, once the files are deposited via SWORD, a direct link is
captured to that item in the repository...and that direct link appears in 
BibApp. 
(Note: This whole process is still a little buggy for Fedora & EPrints, but 
we'll be
cleaning it up for the 1.0 release).

I'm just trying to get a sense if one of these options would end up meeting the
request that you are talking about (esp. something like #2 above), or if you 
meant
something else by the "field for a url to link to the article/work".

- Tim

Original comment by tim.dono...@gmail.com on 11 Jun 2009 at 6:10

[GoogleCodeExporter]

Hi Tim,

I haven't tested depositing via SWORD, yet, but will certainly do that. Having 
that 
direct link will be important.

In the past couple weeks we (Boston University Libraries) have decided that an 
important component of our Open Access/Institutional Repository effort will 
involve 
developing a complete list of publications for each faculty member. This will 
eventually feed not only the IR (DSpace), but the faculty CV, annual report, 
and 
promotion/tenure process.  This will include all publications regardless of 
format 
(books, journal articles, audio recordings, etc.) We want to deposit as much to 
the 
IR as possible, but would like to link to those digital objects that we can't 
include 
in the IR.  DOI will obviously address the need when a doi exists, but not all 
objects will have one. I know that when we harvest metadata from a publisher 
site in 
RefWorks or Zotero, for example, the URL (normally durable) is stored in the 
entry in 
the citation database. My suggestion about the URL field assumed that if it was 
present, that it might be parsed and included in the BibApp record as a part of 
the 
batch load process. 

Haven't tried the "Find It" button yet. That may address most of our needs.  
I'll do 
some testing of that and get back to you.

Jack

Original comment by jwaCo...@gmail.com on 12 Jun 2009 at 12:20

[GoogleCodeExporter]

Jack,

Just to follow up...our IR coordinator at Illinois, Sarah Shreeves, also 
confirmed
there would likely be many cases where a general URL could be useful (e.g. as 
you
mentioned there may not be a DOI, and the local Library "Find It" search may not
always find the content).  

So, I'm going to keep this open as a general ToDo.  I don't think this should 
be a
huge change, so I would anticipate it should be added by our 1.0 release.

Thanks for the good idea...definitely feel free to keep them coming!

Original comment by tim.dono...@gmail.com on 12 Jun 2009 at 2:07

[GoogleCodeExporter]

Original comment by waingram on 25 Jun 2009 at 6:19

• Changed state: Started

[GoogleCodeExporter]

Hi Tim, Jack: Our Work add/edit forms now allow for multiple URLs (DOI, etc) to 
be
associated with each Work.  Manual data-entry for BibApp 1.0 will be vastly 
better
than previous versions.

Cheers,
- Eric

Original comment by ewlar...@gmail.com on 3 Sep 2009 at 1:52

• Changed state: Fixed