Someone raised the idea of using an open archives-compliant harvesting
mechanism for pushing/pulling metadata around. Been thinking about that
one for a long time, too. The fundamental problem with that approach that
I can't get around is that it centers around the concept of fixed
identifiers. Its real purpose, interoperability and passing around of
metadata, all requires true 'fixity' or whatever the word is. It's there,
right in the spec, that "a long-term storage mechanism" is a crucial
Thus if you are imagining something like docster as an
institutionally-managed content archiving solution, using open archives
I'm still stuck, though, on the idea of what Roy Tennant calls "pulsing
content" notion of file sharing systems, where you never know what will be
there from one moment to the next. It seems possible that clients could
be built to generate unique internal ids, and that their local content
could be reported up to an institutional server with the metadata id bound
to their nick or network id or whatever, and that this could be shared,
and updated frequently. In such an environment a query at any given
moment would give an accurate picture at that moment, just like with
napster. This might be somewhat abated if individuals' storage were
persisted with institutional file or web servers somehow, but that could
concentrate legal inquiry more immediately at the server-providing
institutional level, rather than the individual.
So I guess I'm thinking that then open archives harvesting mechanism (or
some variation on the dienst protocol from which it descended) might be
useful as an API-level specification. But from where I'm approaching this
(that, as Mark also said, a solid metadata description/matching
environment, rather than a named identifier-based search environment might
be better) it would be a direct perversion of the intent of open archives.
There's no inherent reason to avoid overloading the intent of a well-known
spec... sometimes it can lead to great things, and this might be an
opportunity for that. But anyone doing things this way would do well to
be _very_ up front about that, right at the outset. And make no claims to
be other than an implementation with distinctly different intent.
On a related issue: does anyone on this list know the ISO ILL protocols
(10160, 10161-1, etc.) well? I just returned from a health sciences
libraries conference in Newport (beautiful city, btw!), where I was able
to talk for a bit with Jay Daly. Medical librarians all over this
continent know Jay well for his work on QuickDoc, a multi-purpose
Docline-intertwangled ILL management tool. Docline, the U.S. National
Library of Medicine's landmark and long-running tool for routing ILL
requests, is going through significant migration pains right now.
They've recently overhauled their systems, but have delayed adding in ISO
protocol support. Which, to me at least, seems an aggregiously poor
migration strategy, as none of our ILL management tools with ISO support
built in can use it for Docline access right now and instead need to
interface with NLM's short-range replacement environment. I.e. this
thing's a moving target, whereas ISO ILL is known and already well-used.
See my point?
Anyway, Jay has said that one of the problems delaying broader ISO ILL
support in general is its size and flexibility. Heard this one before?
It's a much bigger standard than it needs to be, able to handle lots of
complicated scenarios that model existing practices.
We discussed that it seems likely that a very strict and narrow subset of
these protocols might be implemented in a simple-to-generate XML message
stream. This might be a good approach because it would use well-known
standard semantics for tasks like identifying institutions and such, but
still be lightweight for implementation.
I haven't read these specs myself for a while, so I'll read back through
them and report back. Though I hope there's an expert already lurking...