On Mon, Aug 25, 2008 at 15:45, Bernhard Eversberg <ev_at_biblio.tu-bs.de> wrote:
> Alex, it looks like a once-in-a-lifetime opportunity, so grab it and run!
I've left the building, somewhat in disgust, and I now have to push
different bytes around to make a living. But it shouldn't take more
than a half-dimmed library manager with a spark of passion to fund
such a task for a couple of months to a threesome of smart developers.
But then, there's the vendor problem. Anybody worth their salt who
could kick some vendors into helping you out? (I know Talis is a
pretty damn smart bunch, already on the right track ...)
> But seriously, I'm still convinced that XML as such is little more than
> a punctuation standard. Only with massive amounts of tricky additional
> resources can you create something with a bit of content awareness.
Rubbish. With the XML standard alone (say, version 4) you can create a
complete emulated Topic Map of any field you require, including an
ontology and meta data to boot. Done it before, can do it again. But
if the folks who see it don't understand the semantics and the XML
goodness, then why bother?
> Here's the "Big Picture": http://kensall.com/big-picture/bigpix22.html
Wow, look how many library standards there are in there ... *grin*
> Well, not all of it is essential, but a lot. Think of all the tools
> involved, and that you have to have the proper versions of everything
> all the time...
I'm not proposing to use the full XML stack (and the "Big Picture" is
seriously overkill and overlap en masse), but just the basic XML
premise. Here's an example ;
<record xml:lang="no">...</record>
Already here I know what language the record is encoded in. How about ;
<record xmlns:frbr="http://...">
<id frbr:Identity="http://..." ... />
</record>
... for simple identity control? How about mapped relationships?
<record xml:id="123" xmlns:frbr="http://...">
<item frbr:Identity="http://...one" ... />
</record>
<record xml:idref="#123">
<id frbr:Identity="http://...two" ... />
</record>
Or transitional ontologies?
<record xml:idref="#123">
<title xml:idref="#some_other_record">Some title</title>
</record>
And once you get to this stage, and as RDF tools mature?
<record xml:idref="#123" xmlns="rdf"
rdf:about="http://..."
/>
A few RDF statements, even DC based or God forbid FRBR sprinkled *on
top* of your existing XML (be it MARCXML or otherwise) can *seriously*
extend your data with being backwards compatible. Haven't touched on
anything except XML and an RDF example so far, and neither requires a
lot of work to, eh, work.
> You might want to look here as well:
> http://xmlsucks.org/but_you_have_to_use_it_anyway/does-xml-suck.pdf
> It's not really enchanting. Can it be that we end up with XML solutions
> with a sum total of more complexity than MARC solutions? And for the
> same reason: everybody does it.
Yup, everybody does XML. Only libraries do MARC or MARCXML. Go figure.
> More soberly, there must have been a number of attempts meanwhile at
> doing the obvious with XML. Where are the successes?
They're elsewhere, not in the library world.
> If we want to give the world simple solutions, then a JSON-based
> model might also do a good job at lots less of the cost.
Ugh. Look, JSON is fine for simple stuff, but for serious stuff you a
tad bit of rigor on top, especially in the dark schema corners of the
world.
> There are more alternatives, but for these, too, I wonder why no-one
> has come up with an approach to relieve our calamity.
Because the library world is seeped in MARC, and you need balls the
size of Alaska to change it. No, you don't need money, just balls,
male, female, doesn't matter.
Alex
--
---------------------------------------------------------------------------
Project Wrangler, SOA, Information Alchemist, UX, RESTafarian, Topic Maps
------------------------------------------ http://shelter.nu/blog/ --------
Received on Mon Aug 25 2008 - 08:39:10 EDT