Comments on "The OAI2LOD Server: Exposing OAI-PMH Metadata as Linked Data"

Bernhardt and Bernhardt,

I saw your article chumped on the SWIG IRC channel.
I had been looking for almost exactly what you have produced, to get  
into dspace and eprints systems.

1. Is it not practical to make a general gateway which, by including  
the whole URI of the OAI endpoint in the URI in the linked data  
mapping, I could use the gateway to access LOD about any OAI resource  
in the world?

I wonder whether it is the fact that you have to cache most of the  
site. Why is that, for speed, or because you can't get all the links  
you want by asking the OAI server, and so so yo have to have a copy of  
the data as a graph?  Could those aspects of the data which can be got  
from an OAI fetch be proxied at LOD request time, and not cached  
permanently, to save memory?

One interesting issue is the fact that the instance of OAI2LOD needs  
to be started with some background data. That makes an automatic  
gateway difficult, unless there is some way of extracting the data  
from the OAI server itself.

2. Assuming now that you do have to run a separate OAI2LOD instance  
for each OAI endpoint, do you think it would a good idea to make the  
convention that the URI

	oai:lcoa1.loc.gov:loc.gdc/gcfr.0018_0163

is served from a server at a DNS  ("oai" dot (the DNS name in the OAI  
URI))? Like

	http://oai.lcoa1.loc.gov/resources/item/oai:lcoa1.loc.gov:loc.gdc/gcfr.

or even maybe like

	http://oai.lcoa1.loc.gov/item/loc.gdc/gcfr.

One could build into clients a mapping redirection, or in the short  
term configure a generic proxy to do the redirection and configure  
existing browsers to use that proxy for the oai: scheme.  It would  
only happen when following an oai: link, as after that the client  
would be in the world of http: names.


3. The use of "sameAs" to link the same work in different  
repositories.  Is that really what you mean? It allows any properties  
of one URI to be associated to the other URI.  So you can't have any  
properties about the work which only apply to that repository, like  
curation, persistence, etc
I have created a sameWorkAs to get around this problem, in the generic  
resource ontology
http://www.w3.org/2006/gen/ont#sameWorkAs
SameWorkAs should allow one to transfer properties of the generic  
resource, like copyright holder, author, genre.  But not language,  
curator, byte length, delivery format, etc, which vary repository by  
repository would not transfer across sameWorkAs.

The TAG discussed this issue recently.

I'm on a plane or I would be tempted to try out OAI2LOD directly.
(MacKenzie, have you tried this on MIT Dspace?)

Tim

Received on Sunday, 27 April 2008 12:33:42 UTC