Re: Dynamic vs. Fixed World Views was Re: MARCXML to Topic Maps? MODS to Topic Maps?

Hmm,

Patrick Durusau <patrick-Q/[email protected]>:
> You really should ask before presuming what I will or will not say/agree to,

"At this point I am sure Alex is going to object that ..."

...

> But, she hasn't thrown in the towel and neither will I.

No one has thrown in the towel, including yours truly.

> But my "reality" does not include Alex's despair. Perhaps that is the
> difference.

No, the main difference is that you are a librarian - a real one with
superpowers! - and I was just a wannabe but now just a bumbling fool
amongst the gentiles, and as such we see the library legacy from two
very different angles.

...

> I don't disagree that MARCXML could be improved, but what's your point?

I thought that I made it pretty clear ; it's a shoddy format that
helps no one, and often inhibits real progress.

> I can't remember ever seeing an XML format that I didn't think could be
> improved. ;-)

Oh sure, there's degrees of badness in XML design. However, on a scale
from 0 to 100 where 100 is the perfect design, I rate MARCXML a 3.
It's that bad, and that's after I gave it points for at least being
well-formed.

> I think you are way too hung up on the presentation of the data. Sure, MARC
> records are difficult to read, rely on whitespace, etc.
>
> All of that is presentation. Don't like that presentation, write another one
> and view it that way.

That's not presentation, Patrick, this is MARC proper. Having various
characters in your various fields that aren't part of the actual meta
data, *that* is presentation, and not only that but presentation that
makes the meta data even less valuable. Have a look (and don't be
fooled by the XMLishness of this; you'll find this stuff in binary
MARC as well) ;

<marc:subfield code="a">New York, N.Y. :</marc:subfield>
<marc:subfield code="b">Atlantic,</marc:subfield>
<marc:subfield code="c">[1957?]</marc:subfield>

See those : , [ ] stuff? You might think that is presentation, but it
is not. This is *part* of the MARC standard. Many ILS systems rely on
these presentation artifacts, because they are assumed to be part of a
MARC record. I kid you not. And it became standard because back in the
olden days of 70-80's, when librarians printed out MARC records of
given books it looked funny and was a bit hard to read, so they added
this so that it printed nicely. And that is legacy embedded in all
library systems to this day. Seriously.

> Where I strongly disagree is with the statement:
>
>> You need to make
>> sure that one piece of prose is the same as some other piece of prose,
>> and there is *no* easy way to do that. In fact, the only people who
>> have the expertize to pull that off are the librarians.
>
> Sorry, that is the sort of provincial bullshit that created the problem in
> the first place.

No, you just need to be a bit careful about context, because here I
was specifically talking about the context within MARC, or what I call
the culture of MARC (which usually amounts to MARC21 using AACR2 with
a few special additions and best-practices thrown in). So this is not
bullshit; you need to make one piece of prose match another, because
MARC fields are *often* prose rather than typed or enumerated data.

...

> Sure, lots of it will be wrong so there needs to be an easy correction
> mechanism for *all the disgruntled* librarians you know of to do something
> more effective that bitching to each other about management not changing.

Let's be clear; I'm not bitching about management not changing. I'm
crying about the library world which we are about to lose.

...

> Yes, cleaning up data, from a subject identification perspective, is always
> going to be hard work.
>
> When did I ever say otherwise?

I'm not actually sure what you're saying anymore. You say go for it,
it's going to be hard, and I'm saying the exact same thing, so I still
don't understand this disagreement. I guess you're just not happy with
me not being happy about the library legacy.

...

> BTW, what is killing your attempts can be summarized with "...they need to
> completely convert to a new model."

You've heard of FRBR, right? And you've been involved in the RDA
debacle, yes? If no, then perhaps you need to go back and read what I
wrote. If yes, go back and read what I wrote again, because your
summary is incorrect.

...

> If a librarian wants to *not* see the explicit subjects that I added and
> want to view a MARC record with space delimited formatting, that should be
> an option. MARC records are a *presentation* issue.

Do you seriously believe this? Just presentation?

> In the Cross and the Switchblade, one of the people recounts a story of how
> to take a bone away from a hungry dog. You can try to simply take the bone
> away (your approach) and you are likely to get bitten. The bone is all the
> dog has. The alternative is to drop a steak down next to the dog. He will
> drop the bone voluntarily and pick up the steak. (the approach I am
> advocating).

Straw-man arguing. That is not what I'm saying at all. But I'm giving
up at this point, mostly because in every other mail you're expertly
misrepresenting what I say. You just get me wrong, and there seems to
be nothing I can write to fix that. So, everybody, off you go and play
with MARC and Topic Maps. Don't let me get in the way. Have fun.


Alex
-- 
 Project Wrangler, SOA, Information Alchemist, UX, RESTafarian, Topic Maps
--- http://shelter.nu/blog/ ----------------------------------------------
------------------ http://www.google.com/profiles/alexander.johannesen ---