[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
--------------------------------------------------------------------------