Hi Mike:
I can see the merit in that (throw away all the SRU schemas), but the thing
that bothers me is new schema being registered (which I am currently anyway
in process of doing for PAM :).
The problem is that we are dealing with different applications and different
communities with their own perspectives and agendas.
I wouldn't necessarily want to have to submit an XML schema intended for an
SRU search app to the OpenURL approval process without that process becoming
more agnostic as to its application. I'm not familiar with how that process
operates but feel that it might not be as straightforward as all that. The
process is anyway outlined here [1] and includes periods of trial use.
For now, though, I am going to continue to register the schema we need with
the current SRU registry.
Cheers,
Tony
[1] http://alcme.oclc.org/openurl/docs/pdf/SubmittalProcess.pdf
On 20/5/09 14:06, "Mike Taylor" <[log in to unmask]> wrote:
> Ray Denenberg writes:
>> (Hopefully this formats better.)
>>
>> Ross Singer initiated this discussion, first on code4lib, and subseqently
>> (at my suggestion) here and on OpenURL.
>>
>> Unfortunately it caught on only on code4lib, and the thread there quickly
>> degenerated into incoherence. I request that we discuss the issue here,
>> and/or OpenURL (and not on the code4lib list) and preferably on one list
>> only, and my preference would be here.
>>
>> The issue, synthesizing Ross's message:
>>
>> SRU has an XML schema registry at
>> http://www.loc.gov/standards/sru/resources/schemas.html
>>
>> OpenURL has a registry of metadata formats:
>>
>> http://alcme.oclc.org/openurl/servlet/OAIHandler?verb=ListRecords&metadataPre
>> fix=oai_dc&set=Core:Metadata+Formats
>>
>> it includes (but is not limited to) XML schemas.
>>
>> OpenURL and SRU are using different info URIs to describe the same things.
>>
>> For example:
>>
>> info:srw/schema/1/marcxml-v1.1 and info:ofi/fmt:xml:xsd:MARC21
>>
>> orinfo:srw/schema/1/onix-v2.0 info:ofi/fmt:xml:xsd:onix
>>
>> Is it possible/feasible to agree on one or the other, or will (must) we
>> continue to use the SRU-registry identifiers for SRU and the OpenURL registry
>> identifiers for OpenURL?
>>
>>> From my point of view we would need to come to agreement (if any) on this
>>> fast (at least agreement in principle), because of a number of initiatives
>>> currently in progress, and if we can't then we would just keep using thedual
>>> systems.
>>
>> Comments please.
>>
>> (I really do strongly request that we resist the temptation to take this
>> thread off-course, like making absurd suggestions that the identifer for a
>> schema should be its namespace URI. If you want to talk about that, please
>> initiate a new thread.)
>
> I propose the simplest possible solution (and also the only one that
> we, the ZING community, can implement unilaterally: let's throw away
> the SRU-specific schema identifiers and use the OpenURL ones in SRU.
> If we do that, then hopefully our example will encourage others (OAI?)
> to follow suit.
>
> (Needless to say, well-behaved SRU servers would still continue to
> recognise the old schema identifier URIs, as not all clients will
> change over immediately.)
>
> _/|_ ___________________________________________________________________
> /o ) \/ Mike Taylor <[log in to unmask]> http://www.miketaylor.org.uk
> )_v__/\ "You cannot really appreciate Dilbert unless you've read it in
> the original Klingon." -- Klingon Programming Mantra
********************************************************************************
DISCLAIMER: This e-mail is confidential and should not be used by anyone who is
not the original intended recipient. If you have received this e-mail in error
please inform the sender and delete it from your mailbox or any other storage
mechanism. Neither Macmillan Publishers Limited nor any of its agents accept
liability for any statements made which are clearly the sender's own and not
expressly made on behalf of Macmillan Publishers Limited or one of its agents.
Please note that neither Macmillan Publishers Limited nor any of its agents
accept any responsibility for viruses that may be contained in this e-mail or
its attachments and it is your responsibility to scan the e-mail and
attachments (if any). No contracts may be concluded on behalf of Macmillan
Publishers Limited or its agents by means of e-mail communication. Macmillan
Publishers Limited Registered in England and Wales with registered number 785998
Registered Office Brunel Road, Houndmills, Basingstoke RG21 6XS
********************************************************************************
|