Good morning, Tim.
I think that you're right about populating the appropriate fields on the
repository side.
It looks like the OAI-PMH generator for your repository is placing the
identifier (URL) in the unqualified identifier field, instead of
identifier.uri. This is common, as many OAI-PMH gateways will only support
the OAI-DC metadata format, which does not include the qualifiers, by default.
If you can configure your repository side to generate another metadata format
that will place your identifier field in identifier.uri, that would allow
DSpace to identify your URL when it harvests. An example is the qdc format
that the DSpace 1.6 harvester supports.
The DSpace harvester also has a couple of parameters in the configuration file,
harvester.acceptedHandleServer and harvester.rejectedHandlePrefix, that can
prevent DSpace from generating that extra hdl.handle.net URL. They are
documented in the configuration file.
If you're unable to place your original URL from the repository in
identifier.uri, you may still be able to work around this by changing the
interface in DSpace to display the unqualified identifier field next to the
URI: label on the item view pages. You'd probably want to limit this so that
it only does so if the identifier starts with http://scaa.suask.ca; in case
your repository also maps citations, issn, doi to that field.
There are some interface HOW-TOs on the wiki that may help, and people on this
list with experience in changing the display for the jspui and the xmlui, if
you need to go that route.
--keith
- Mensaje original -
De: Tim Hutchinson tim.hutchin...@usask.ca
Para: dspace-tech@lists.sourceforge.net
Enviados: Viernes, 7 de Mayo 2010 15:58:55 GMT -05:00 Región oriental EE.
UU./Canadá
Asunto: [Dspace-tech] harvesting non-DSpace repositories - dc.identifier.uri
issue
Hi,
I have been involved in testing DSpace to harvest a collection not
hosted in DSpace, but which is OAI compliant. We have been successful in
doing the harvesting, but not successful in having the DSpace record
point to the correct external record.
The issue is that DSpace assigns a URL of the form
http://hdl.handle.net/123456789/x
to dc.identifier.uri
although dc.identifier appears correctly, e.g.
http://scaa.usask.ca/gallery/northern/image.php?ID=10857 (the main
problem is that the correct identifier is not hyperlinked, and doesn’t
appear in the simple view)
As you can see, we are running a test implementation of DSpace and have
not implemented the handle server, hence the “123456789” prefix. But I’m
not sure that’s the only issue.
What I’m wondering is:
- Is there a way, by populating appropriate fields on the repository
side or by configuring DSpace, or otherwise, to have the correct
identifier (URL) show up in dc.identifier.uri, especially for the
purpose of the test implementation?
- Will implementing the handle server actually solve the problem? It’s
not clear to be how this will work, since wouldn’t we need to register a
prefix (or at least set up a mapping) for each external collection? As
may be obvious, I'm not too familiar with how handles work.
As additional background, I did also test with a repository using the
OAI identifier format, i.e. oai:domain:id. The element dc.identifier
resolves correctly, but dc.identifier.uri still uses the non-functional
handle. On the other hand, harvesting from a DSpace collection works
properly, with dc.identifier.uri being populated with the handle
assigned by the other DSpace instance.
In case it makes a difference, we are running DSpace version 1.6.0.
Thanks for any guidance on this.
Tim
--
Tim Hutchinson
University of Saskatchewan Archives
301 Main Library, 3 Campus Drive
Saskatoon, SK S7N 5A4
tel: (306) 966-6028
fax: (306) 966-6040
e-mail: tim.hutchin...@usask.ca
web: http://www.usask.ca/archives/
--
___
DSpace-tech mailing list
DSpace-tech@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-tech
--
___
DSpace-tech mailing list
DSpace-tech@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-tech