Ray Denenberg, Library of Congress writes:
 > Thanks, Ross. For SRU, this is an opportune time to reconcile these
 > differences. Opportune, because we are approaching standardization
 > of SRU/CQL within OASIS, and there will be a number of areas that
 > need to change.

Agreed. Looking at the situation as it stands, it really does seem
insane that we've ended up with these three or four different URIs
describing each of the data formats; and if we with our library
background can't get this right, what hope does the rest of the world
have? Because OpenURL 1.0 seems to have been more widely implemented
than SRU (though much less so than OpenURL 0.1), I think it would be
less painful to change SRU to change OpenURL's data-format URIs than
vice versa; good implementations will of course recognise both old and
new URIs.

 > Some observations.
 >
 > 1. the 'ofi' namespace of 'info' has the advantage that the name,
 > "ofi", isn't necessarily tied to a community or application (I
 > suppose one could claim that the acronym "ofi" means "openURL
 > <something starting with 'f'> for Identifiers" but it doesn't say
 > so anywhere that I can find.) However, the namespace itself (if
 > not the name) is tied to OpenURL. "Namespace of Registry
 > Identifiers used by the NISO OpenURL Framework Registry". That
 > seems like a simple problem to fix. (Changing that title would not
 > cause any technical problems. )
 >
 > 2. In contrast, with the srw namespace, the actual name is
 > "srw". So at least in name, it is tied to an application.

Agreed -- another reason to prefer the OpenURL standard's URIs.

 > 3. On the other side, the srw namespace has the distinct advantage
 > of built-in extensibility. For the URI:
 > info:srw/schema/1/onix-v2.0, the "1" is an authority. There are
 > (currently) 15 such authorities, they are listed in the (second)
 > table at http://www.loc.gov/standards/sru/resources/infoURI.html
 >
 > Authority "1" is the SRU maintenance agency, and the objects
 > registered under that authority are, more-or-less, "public". But
 > objects can be defined under the other authorities with no
 > registration process required.
 >
 > 4. ofi does not offer this sort of extensibility.

But SRU's has always been a clumsy extensibility mechanism -- the
assignment of integer identifiers for sub-namespaces has the distinct
whiff of an OID hangover. In these enlightened days, we use our
domains for namespace partitioning, as with HTTP URLs.

I'd like to see the info:ofi URI specification extended to allow this
kind of thing:
info:ofi/ext:miketaylor.org.uk:whateverTheHeckIWantToPutHere

 > So, if we were going to unify these two systems (and I can't speak
 > for the SRU community and commit to doing so yet) the extensibility
 > offered by the srw approach would be an absolute requirement. If
 > it could somehow be built in to ofi, then I would not be opposed to
 > migrating the srw identifiers. Another approach would be to
 > register an entirely new 'info:' URI namespace and migrating all of
 > these identifiers to the new namespace.

Oh, gosh, no, introducing yet ANOTHER set of identifiers is really not
the answer! :-)

 _/|_ ___________________________________________________________________
/o ) \/ Mike Taylor <[log in to unmask]> http://www.miketaylor.org.uk
)_v__/\ "Conclusion: is left to the reader (see Table 2).
Acknowledgements: I wrote this paper for money" -- A. A. Chastel,
_A critical analysis of the explanation of red-shifts by a new
field_, A&A 53, 67 (1976)