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

Alex,

Let me jump to the only substantive disagreement we seem to have, that 
over whether MARC is just presentation.

Realize that I come at this from a heavy markup background.

That is to say when we say <p></p> we haven't invented anything, we are 
simply representing something we have observed in the text that was not 
explicit.

That is to say that paragraphs occur in text whether they are marked 
with <p></p> or not.

All that is old hat but I mention it to start us off from a common 
starting point.

 From my perspective, formats, such as MARC are *representing* something 
that exists whether it appears in MARC or MARCXML or in some other 
*presentation.*

Some presentations/formats are more powerful than others. And we can 
study them as artifacts in their own right but that wasn't what I was 
suggesting below.

What I was suggesting, apparently offensively, was that with 
sufficiently granular mapping into a topic map that if someone ask for a 
standard MARC presentation of the same data, that could be delivered.

I don't find that a particularly remarkable statement.

Hope you are having a great weekend!

Patrick

PS: I did not intent to mis-represent anything you said. If that was the 
case, however inadvertently, my apologies.

On 7/18/2010 8:26 AM, Alexander Johannesen wrote:
> 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
>    

-- 
Patrick Durusau
patrick-Q/[email protected]
Chair, V1 - US TAG to JTC 1/SC 34
Convener, JTC 1/SC 34/WG 3 (Topic Maps)
Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300
Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps)

Another Word For It (blog): http://tm.durusau.net
Homepage: http://www.durusau.net
Twitter: patrickDurusau