[OAI-implementers] Requesting a part of a record possible wit h OAI-OMH?

Ann Apps ann.apps@man.ac.uk
Thu, 22 Jan 2004 13:42:05 +0000


Hi All,

It is good to see some interest in our IESR service metadata 
descriptions. But I think I should point out that it is still very much 
'work in progress' - and our documentation is probably not perfect! 
Currently the main effort is going into getting a prototype of the 
registry working.

Also, as Andy said, it is being developed within a specific domain 
of UK HE. That said it would be good to receive comments and 
work with people outside that domain. We 'invented' the IESR-
specific metadata properties because there did not seem to be any 
standard, or generally accepted, metadata for our purpose, as far 
as we were aware. The metadata uses standard or standardish 
metadata where possible.

Very brief description of the data within the registry: The main 
purpose is to describe collections that are funded by JISC for use 
by researchers, learners, teachers in UK higher and further 
education, and probably in the future other collections of use to 
them. And to describe services, ie low-level machine access 
points, that provide access to those collections. But we also want 
to describe services that are not collection-based (that we have 
termed 'transactional'). The most significant examples of these are 
OpenURL resolvers (without getting into philosophical discussions 
about 'what is a collection', etc!). So we have 2 types of entity to 
describe: collection and service. We also have agents that can be 
owners of collections and/or administrators of services but they are 
not of much interest. 

The collections are described mostly by RSLP Collection 
Description - hopefully will be migrating towards DCMI Collection 
when that is more agreed.

For the services we found we had to invent some metadata 
properties. Most significant is 'iesr:interface' that gives m2m details 
about how to acess the service. As Andy said, we didn't want to 
reinvent the wheel, so we have used standards where possible. So 
we use WSDL for SOAP services and Zeerex for Z39.50, SRW, 
etc. OAI-PMH doesn't need an interface description - potential 
users can interrogate the service itself. The only ones we couldn't 
describe like this are general web-cgi services. At the moment we 
are creating a proprietary 'keys' file to describe these - with the 
'interface' property pointing ot it. But, as Pete said, we intend to 
look for a more standard way of describing these.

Eventually we will have an XML schema to describe the metadata 
formally (we have only a DTD at present, that being a requirement 
for the software platform). And we intend to provide an OAI-PMH 
interface to allow harvesting of the records.

Hussein Suleman on Thu, 22 Jan 2004 wrote:

> hi Andy
> 
> it looks most interesting ... here are some thoughts:
> 
> - your descriptions are for an independent external registry, while i
> was proposing a "friends"-like services offered on the same archive.
> as such, "title" would be a moot point, while you (rightly) require
> it.

> - your service identifiers are assigned by a central authority - with
> a self-description, that should not be necessary (and may even violate
> some information independence principles)
> 
We needed unique URIs for the entities in the registry and there did 
not appear to be any already in existence at the time when we 
designed this. Though some collections may have URIs and we 
would expect to use those rather than assigning a new identifier.

> - you do not have a formal identifier for the protocol and i think
> that is quite important to match clients and servers for services. i
> was suggesting the canonical URI of the protocol specification. 

This is probably a failure in the documentation. The names we use 
oai-pmh, webcgi, z3950, are just tokens and I agree they should be 
defined by URIs. I expect that finally the definitions of the IESR 
controlled vocabularies will be held within a IESR meta-registry, 
that also knows about IESR entitiy identifiers and their 
relationships. I would intend to improve their definitions at that point.

> If someone comes up with a new CGI-based protocol, they SHOULD have a
> specification written down somewhere, otherwise i don't see the point
> of advertising the interface publicly.
> 
This is probably true. However we have to deal pragmatically with 
reality :)

> - WSDL is tricky. did you use the draft spec or the technical note?
> there are encoding differences between the two, so until this becomes
> a standard, i am keeping my distance.
> 
>From some work we've done to discover requirements from our 
stakeholders (data suppliers and eventual users), there is a clear 
requirement to describe SOAP services. However, there don't yet 
appear to be many actual services to describe. So this is really 
looking to the future and we haven't delved too deeply into WSDL 
yet. Also the WSDL is defined by the metadata (and hence 
service) providers, not by us.

For other service protocols, eg RSS, Z39.50, OpenURL, we have 
include a metadata property 'supportsStandard' that allows for 
description of the particular versions and profiles a service 
supports. I would expect to augment this list with WSDL versions 
in the future.

> - access rights may be useful. administrator may be covered already
> (by adminEmail). contributor is again not relevant in this case, but i
> see that that is optional anyway so it doesnt matter.
> 
These properties are more to do with the domain in which the IESR 
operates, and to provide information to humans.

> so ... do you think these differing requirements can be merged? (im
> still not sure where/how i will use this yet, but at least a few other
> seem interested as well).
> 
> ttfn,
> ----hussein
> 
Best wishes,
	Ann
> 
> Andy Powell wrote:
> 
> > On Wed, 21 Jan 2004, Young,Jeff wrote:
> > 
> > 
> >>I was thinking of using custom description schemas to define these
> >>things for the ERRoL service, but if there is a commonly accepted
> >>mechanism, all the better.
> > 
> > 
> > The JISC Information Environment Service Registry Pilot Project (cor
> > blimey, that's a bit of a mouthful! :-) ) is developing an
> > experimental registry of the collections and services that make up
> > the UK higher education information landscape.  See
> > 
> >   http://www.mimas.ac.uk/iesr/
> > 
> > for details.  As part of this work, the project has developed an
> > 'application profile' for describing various kinds of services,
> > including Z, SRW, SOAP, CGI, RSS, OAI-PMH, etc.
> > 
> > I'm not sure how easy you'll find it to work your way thru the
> > pages, but the application profile and some examples are linked
> > from:
> > 
> >   http://www.mimas.ac.uk/iesr/metadata/
> > 
> > You'll note that for SOAP-based services like SRW, the 'service'
> > descriptions link to an external WSDL file, rather than re-inventing
> > the wheel.
> > 
> > Andy
> > --
> > Distributed Systems, UKOLN, University of Bath, Bath, BA2 7AY, UK
> > http://www.ukoln.ac.uk/ukoln/staff/a.powell/      +44 1225 383933
> > Resource Discovery Network http://www.rdn.ac.uk/
> > _______________________________________________ OAI-implementers
> > mailing list List information, archives, preferences and to
> > unsubscribe:
> > http://oaisrv.nsdl.cornell.edu/mailman/listinfo/oai-implementers
> > 
> 
> -- 
> =====================================================================
> hussein suleman ~ hussein@cs.uct.ac.za ~ http://www.husseinsspace.com
> =====================================================================
> 
> _______________________________________________
> OAI-implementers mailing list
> List information, archives, preferences and to unsubscribe:
> http://oaisrv.nsdl.cornell.edu/mailman/listinfo/oai-implementers
> 
> 


--------------------------------------------------------------------------
Ann Apps. Senior Analyst - Research & Development, MIMAS,
     University of Manchester, Oxford Road, Manchester, M13 9PL, UK
Tel: +44 (0) 161 275 6039    Fax: +44 (0) 0161 275 6040
Email: ann.apps@man.ac.uk  WWW: http://epub.mimas.ac.uk/ann.html
--------------------------------------------------------------------------