[XML4Lib] ILS system architectures

[Alexander Johannesen]

Hi,

<rant mode="fed-up" mood="sad">

On 10/28/05, Duimovich, George <gduimovi at nrcan.gc.ca> wrote:
> - Inability of our ILS systems to readily/flexibly extend beyond the MARC
> attribute set (see also that fantastic earlier thread on "When will XML
> replace MARC?").

Given the shere brilliance of the design of MARC 21 XML (note:
sarcasm) and *it* still being "cutting-edge" within the library world,
I reckon that unless some vendor comes up with something smart and
force it upon us all, it ain't happening anytime soon. Given most
vendors I've seen, that ain't happening anytime soon either.

MARC is a *culture* closely knit to both Z39.50 and the amalgam DeweyD
and LCSH, and as long as librarians and our vendors hail this as a
requirment in everything, well, that's what we get really. As you say,
as the culture of the online world *is* changing with new technologies
and mental-models, we too must change with them, or we'll lose out,
possibly to the point of obsoleting the term 'library' as we know if
from future dictionaries.

> When it can be done, most
> vendors won't fully support the standard and direct methods for doing this,
> nor with the freedom to integrate (or interconnect) in a suitable manner...

One thing I've observed in the library world is that we don't feel
like we should *choose* the best solution for us, but wait a little
and see what the others choose first. And since we're all doing this
... *sigh* Well, in the meantime OCLC develops some standard, and
everyone jumps on that, because, you know, OCLC is doing things in the
best interest of libraries, and they're smart and wouldn't produce
sub-par stuff. Or so the legend goes.

Didn't the libraries used to be early adopters and innovators? What
happened? OCLC stuff is not cutting edge. Even stuff talked about as
cutting-edge certainly isn't. What's the latest hype that came up? A
structured Wiki with an integrated DB? Just the thing academic
librarians would think of but hardly what is desperately needed; open,
well-crafted and non-ambigious semantically-rich scemas that are
simple to support, use and extend. Now, FRBR aside, all these models
we throw up on a monthly basis (and heck, I'll include FRBR here, too)
needs some underlying technology to make it work, but so far no one
has seemed to give this much thought, and the result is bucketloads of
different XML schemas. What the..? Why not RDF or Topic Maps? Why not
use something the rest of the world uses with great success, so that
the crumbles can trickle down to us as well?

(And don't get me started on the XML schemas they *do* produce; I
could write a book on the poor design on most of them!)

> - closed architectures: when I read some of the discussion from Access 2005,
> from say L. Demsey, on bringing the library to "where the user is -- on the
> network", it's frustrating to think how many more years it'll be before the
> ILS marketplace changes to truly support this vision.

We *must* focus on open standards. I'm not too concerned with the
architectures and software and all that; if the *format* of our data
is open, I reckon we'll go a long way. And don't say MARC; you'll be
laughed at in public. :)

> I don't want to bash
> the vendors per se

Then let me; what the heck are you thinking? It's well and fine that
you *can* do something in the current clunky ways, but the manner in
which this has been done is countering the library modus operandis; in
the best interest of the patrons! Currently it is expensive, slow,
untidy, at times random, slow, inflexible, and more! In any other
industry this wouldn't be tolerated, so why are we? Why is Z39.50
still popping up as a requirement? Is it because it is better than
Webservices (with or without SOAP, REST or otherwise), or because of
legacy, or because 'we designed it, and heck, we'll use it!' 
Depending on who you ask and when you ask it, the answers are
different, and far too often it falls towards the latter.

> , but when I look at our ILS user's group "enhancements
> requests" I am disturbed by how particular the requests are focussed, when
> in many cases, we wouldn't have to wait for many of these specific
> mini-changes if the "black box" architecture was opened up for our own
> application development! Further, the bias remains heavily towards "library
> workflow" when our users' expectations are driven by $billion Google
> inspired R&D, and the network environment is increasingly moving forward
> with possibilities much faster than our system architectures are supporting
> the exploration and innovation by the "ready and willing."

Lately we had a discussion here about federated searches, and one of
the *key* requirements to whatever protocol we were to choose was
"fielded search." Maybe this comes as a surprise to many, but Google
isn't successful because of fielded search. In fact, they have none.
Zip. Zilch. It's about searching smarter, not more complex, but
unfortunately 'complex' is so engraved into librarian brains that it
is hard to get away from.

'Oh no, you can't use Google for this; it is too complex' I hear it
all the time. And what's funny is that I recently went through our
statistics on our systems and found that our own librarian expert
users, when given the choise of using general search and the advanced
search, 97% used general search (the one without fielded searching).
How many used fielded search? Less than 1% of our *expert* users. Yet,
fielded searching is the *primary* requirement.

Is it just me who sees this absolute craziness, or should I just quit
and become a berry-farmer up north somewhere?

</rant>

--
"Ultimately, all things are known because you want to believe you know."
                                                         - Frank Herbert
__ http://shelter.nu/ __________________________________________________