Thank you for your reply.
I wish I'd have coffee with you.
I read ePrints UK report and "Institutional repositories, aggregator
services and collection development (ePrints UK supporting study, no. 2)".
Rachel Heery wrote:
> - the potential for using repository content in the way you indicate i.e.
> as a search target for resolvers. Given the number of repositories in the
> UK I believe this would mean aggregating metadata from the repositories
> for the terget search. Discussion on this is very preliminary, at least I
> have only talked about it over coffee! It seems to me a good way of
> exploiting the content during the early build-up of repository content.
> Its usefulness would depend on deployment of openURLs, which itself would
> be encouraged by access to repository content.... This idea was mentioned
> as an aside in the final report of the ePrints UK project see
> http://www.rdn.ac.uk/projects/eprints-uk/docs/final-report/eprints-uk-final-20050316.pdf
> I am intending to investigate this approach further, so your mail is very
> timely. I would welcome any further input...
We also have centralized metadata database, which aggregates metadata
from IRs in Japan via OAI-PMH.
JnNii (sorry, in Japanese only)
http://ju.nii.ac.jp/
Though JuNii has its original DC application profile, I think the profile
does not have enough precision and we have to refine it so as to describe
details of the bibliographic citations of IR contents.
> - providing OpenURLs for the citations within deposited eprints. This has
> been demonstrated within the ePrints UK project using the Citation
> Analysis Web service developed by Tim Brody at Southampton see
> http://opcit.eprints.org/ and for technical report on eprints UK demo see
> http://www.rdn.ac.uk/projects/eprints-uk/docs/technical/eprints-tech-report.pdf
Hokkaido University's repository has jtitle, volume, issue, year, spage and epage
separately in its metadata and they are crosswalked into dc:identifier in oai_dc.
However, in our meeting, we discussed not oai_dc but more machine readable
metadataFormat may be needed.
(1) If each institutional repository has sufficiently detailed metadata,
(2) and if there is OpenURL compliant OAI-PMH metadataFormat (temporarily I call it Z39.88),
(3a) and if link resolvers harvest metadata in Z39.88,
(4a) and if they merge the harvested metadata into their knowledgebases,
(3b) or if a service provider "A" exists which harvests metadata in Z39.88,
(4b) and if link resolvers form their navigation windows by refering
the "A", adding to their knowledgebase, CrossRef and some other resources,
(5) then, users can be navigated to their appropriate copy (eJournal or OA repository).
Some of us think (3a)-(4a) causes multiple cost for both of link resolver vendors
and institutional repositories, and (3b)-(4b) can be more efficient way.
We will have an investigation how link resolver vendors thinks about that.
If any ideas and advices, we would be greatly appreciated.
Thank you.
with best regards,
--
SUGITA Shigeki <[log in to unmask]>
University Library, Hokkaido University, JAPAN
HUSCAP http://eprints.lib.hokudai.ac.jp/
OAI-PMH http://eprints.lib.hokudai.ac.jp/dspace-oai/request
|