On Wed, 14 Jul 2004, Scott Wilson wrote:
> > But yes, something I was turning over after reading Andy's initial
> > message on this thread (and which I think is also touched on in John
> > Casey's comment about a repository requiring the "full monty" and Scott
> > Wilson's comment on "prior agreement" about data exchanged between
> > services) is whether there is a potential tension here between the
> > requirements/preferences of a (in OAI-PMH terms) "data provider" (the
> > agent who provides/exposes metadata) - "you can't really expect me to
> > provide *all* this stuff!" - and those of a "service provider" that uses
> > that metadata as the basis of a new service - "I'd really quite like to
> > rely on having present all those elements that UK LOM Core says is
> > mandatory".
> >
> > I don't have an answer for how to resolve that tension! ;-)
>
> In Z39.50 world, this is what the "Explain" request is for - in Web Services
> this is the function of WSDL.
Unfortunately these methods only tell you some of the information that you
need to know. For example, Explain can be used by the client to find out
what search parameters are supported and what record formats are available
to be returned - but it won't tell you anything about the rules that have
been used to create the fields in those records. So you can tell that a
MARC record will be returned, but you can't tell if the MARC record was
created in accordance with AACR2 cataloguing rules.
Similarly, in OAI, the service provider can ask the data provider what
metadata prefixes are supported, and as part of the response to that
request, information about which XML schema is being used is passed back.
So, if there was an XML schema for, say, RLLOMAP, a service provider could
1) prior to beginning harvesting, determine if the records available from
the data provider are likely to be useful in terms of containing the
correct elements and so on (but not in terms of whether particular values
have been constructed according to particular rules).
2) validate individual records as they are harvested and reject ones that
didn't contain mandatory fields.
*But*, we don't currently have an XML schema for UK LOM Core or RLLOMAP -
we just use the standard LOM schema - so we can't do any UK LOM Core or
RLLOMAP specific validation. And, more importantly, such validation
wouldn't tell us anything useful about what rules were used by the
cataloguer when the metadata fields were created.
I still think we need to ask oursleves questions like "What is the purpose
of an application profile?", "What does XML Schema already give us that we
don't need to replicate in the application profile?", "What does mandatory
mean?" and "What are the benefits and downsides of making particular
elements mandatory or not?".
My personal opinion is that the real benefit of something like UK LOM Core
is in achieving greater (but not 100%) consistency in the choice of
metadata elements and the way values are constructed for those elements
across a range of disperate data providers - not about telling consumers
of metadata records from those services which elements will absolutely,
definately be available. So, as the developer of a metadata harvester,
the UK LOM Core doesn't need to tell me with cast iron certaintly that
every metadata record is going to contain 4.2 technical.size for example,
but it should tell me that if the record contains that element then the
value will be constructed according to the following rule - "size in bytes
(a number)".
If my application absolutely needs 4.2 technical.size in order to function
properly, then I can simply throw any records without that element away.
I don't need an application profile to enable me to do that - I just do
it, having looked at each record. But I do need the application profile
in order to make sure that everyone constructs the value in the same way.
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/
ECDL 2004, Bath, UK - 12-17 Sept 2004 - http://www.ecdl2004.org/
|
