[TopicMapsInLIS] Inaugurating the list

[Liliana Melgar E.]

Thank you Alexander for sharing your dream, the serious librarian dream!

Do you know something about the AACR3 and the future of MARC? It seems to me
that the efforts are divided in the library community, and most of the time,
the new initiatives want to invent the wheel again and don't take into
account previous efforts. The good thing about TM is that it could bring
that associativeness... But then, what about RDF?

greetings,

Liliana

2007/11/27, Alexander Johannesen <alexander.johannesen at gmail.com>:
>
> On Liliana Melgar E. <lilimelgar at gmail.com> wrote:
> > Maybe TM could be not only a good application for the
> > library catalog itself, but to connect all this way to organize
> > information within a library...
>
> Not only that, but it could in fact solve the very interop problem our
> library systems are riddled with ; it is, after all, a system designed
> to handle complex meta data in really smart ways. There's no end to
> the things in our world that would fit so beautifully into the Topic
> Maps paradigm where the built-in mechanism for merging Topic Maps from
> various domains is like a wet dream for any serious librarian. (It was
> a wet dream for me, at least, which is why I decided to work for the
> library world to see what I could accomplish.)
>
> I've had many stabs at trying to make an ontology for AACR2 / RDA data
> (or, if you will, whatever people these days stuff into MARC), but
> unfortunately all my efforts break down because of meta data quality
> and uniformity, and the complete lack of typed data (which is why it
> was so fabulously easy to make a MARC to MARCXML converter ; who needs
> types and validation, right? :). The library world knows about the
> theories of [persistant] identification, but they truly are terrible
> at applying it in practice.
>
> The body of MARC data is fun to search (as in "wouldn't it be fun to
> see if we found what we're after" kinda way) but hopeless to rely on
> in a typed way. For that to happen all the libraries need to undertake
> a "clean up our meta data" international project, and acually agree on
> a common set of rules and standards the library world would like to
> use. No, I don't mean AARC2, as there are of course various ways,
> formally or otherwise, to interpret it to fit some need. I mean, we
> need to agree to what it really, really means. DC was on the right
> track, and a shame that it only got 15 fields long before given up on.
> :)
>
> My best MARC ontology could reasonably well map up / extract data from
> oral history records, unless they got beyond 2000 records, which
> seriously is too small to be of interest. Some serious work need to be
> done in this area, one that I think we *must* do, not for Topic Maps
> sake, but for the future of our meta data. We need routines for
> creating identifiers across vast materials, for sanitizing field data
> (like getting rid of all presentation and notation, or convert
> notation to proper fields), rules for merging, rules for FRBRication
> of records, rules / routines for breaking a MARC record apart (and how
> filtering on those would happen), and on and on.
>
> Of course, this should be ongoing work, not "yet another little
> project that looks at Topic Maps." I think it's fair to say that Topic
> Maps indeed should be used here, that they are technically proven to
> give us huge benefits (especially given the library worlds meta
> modeling desires). And not as a a portal of sorts, but as a basis for
> dealing with really complex meta data. That's what it's *best* at,
> after all.
>
> Anyways, my 0.2$.
>
>
> Regards,
>
> Alex
> --
>
> ---------------------------------------------------------------------------
> Project Wrangler, SOA, Information Alchemist, UX, RESTafarian, Topic Maps
> ------------------------------------------ http://shelter.nu/blog/--------
>



-- 
Liliana Melgar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ligent.net/pipermail/topicmapsinlis/attachments/20071127/03767e62/attachment-0001.html