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

Patrick Durusau <patrick-Q/[email protected]>
Newsgroups gmane.text.xml.xtm.general
Message-ID <[email protected]>
Alex,

Sorry to cut into your Monday (I forgot your time zone, sorry) but:

On 7/18/2010 9:48 AM, Alexander Johannesen wrote:
> Patrick!
>
>    
>>  From my perspective, formats, such as MARC are *representing* something that
>> exists whether it appears in MARC or MARCXML or in some other
>> *presentation.*
>>      
> Yes, I understand this part. However, with this ;
>
> <marc:subfield code="a">New York, N.Y. :</marc:subfield>
> <marc:subfield code="b">Atlantic,</marc:subfield>
> <marc:subfield code="c">[1957?]</marc:subfield>
>
> when you remove the presentation, you get this ;
>
> New York, N.Y. :
> Atlantic,
> [1957?]
>    
Sorry, wrong answer from my perspective.

Even those three lines are being "presented" to the user. Reconstructed 
from very low level constructs and then mapped to glyphs and finally 
presented to the user.

I could transmit that information sans the glyphs to another program, 
even another machine for processing.

What I am suggesting is that if we can capture all the data, if asked, 
we could reconstitute either a MARC or MARCXML "presentation" to the user.

When I say "all the data," I mean exactly that.
> This is the actual meat, this is stripped of presentation. And still
> you got presentation artifacts in there, and this presentation is
> different from practice to practice, even country to country if you
> want to divert in to various versions of MARC. Sure, there is
> presentation, or wrapper if you like, but I'm not whining about the
> presentation / wrapper; I'm whining about the actual stuff in the
> middle, the actual meta data. And here we're talking strictly
> artifacts, but when we dig into a more prose-prone field, it gets a
> heckovalot worse, with abbreviations, markup and undocumented
> relationships to other fields, all sitting somewhere between
> cataloging best-practice and personal negligence.
>
>    
No disagreement on the difficulty and the issues you point out.

>> 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.
>>      
> Oh, come now, there was no offense there, even if I'm passionate about
> this very topic. In fact, I don't even think I'm capable of being
> offended by anything.
>
> On the flip side, you're still not correct. The second you place one
> thing into a different model than where it came from, the meaning
> changes, even in the smallest of ways (versioning, new context, etc.)
> unless you duplicate the original model. Now maybe what you're trying
> to say is to recreate all of MARC (or maybe a mostly used part of the
> model?), and make an additional map on top (it is Topic Maps after
> all) to create a greater richness. Maybe that is doable, but I still
> would call it worthless except to peculiars.
>
>    
Well, it is trivially true that representing a subject in a topic map is 
by definition a different context than its original representation. The 
question then becomes have we represented it accurately enough, for some 
purpose?

It is always going to be an "accurately enough" question but that was 
true for any original representation as well.

If the library community were to want to migrate from MARC to some other 
representation, even topic maps, wouldn't that involve identifying the 
same subjects that would be required for a mapping as I suggest?

Seems like that is going to be necessary no matter what migration, if 
any, take place. Yes?

And why would it be objectionable to add value to an existing data model 
using a topic map?


>> Hope you are having a great weekend!
>>      
> Monday is 30 minutes away ...
>
>    
>> PS: I did not intent to mis-represent anything you said. If that was the
>> case, however inadvertently, my apologies.
>>      
> Let me clarify this one, as it seems to bite the core of this apple. I
> made a statement, claiming "but the MARC dataset is crap. There, I
> said it. It's rubbish for any other purpose than to be worked with and
> searched by trained librarians." Lars M jumps in, and use MARCXML as
> an example of MARC data (I suspect mostly because binary MARC would
> suck in mail form). And you state ; "I don't disagree with Alex on the
> *technical* merits of MARCXML."
>
> But the thing is, I didn't say MARCXML is crap. Well, I said it in a
> different place, but in *this* context I was talking about MARC, or
> more specifically MARC21. That would be a fine little
> misunderstanding, but it did spur on your allegory ;
>
>    
OK,
> "Alex's approach is like the drunk searching under the street lamp for
> his keys."
>
> You're implying quite a dramatic fault in what I say, in my
> "approach", whatever that might be. This hoopla based on the MARC vs.
> MARCXML misunderstanding, nothing more. I don't think you fully
> understand what my approach is, because I'm not the enemy of library
> legacy like I feel you think of me. Just because I'm pointing out that
> they suck doesn't mean they have no value, but it does have
> implications for how we can go about squeezing value from them (and
> I'd strongly advice against re-creating the MARC model and try to
> extend or filter it). I may be annoyed by MARC and totally hate
> MARCXML, but I'm still trying to work with the library community both
> in awareness about their problems (like a lack of identity management,
> and ontological granularity, enumeration and typeification) and
> solutions to it (prototypes, suggested technologies, etc.)
>
> Anyway, now it's only 12 minutes left of Sunday, and I'm in bad need
> of a shower. Good night, and I hope we can continue a more fruitful
> and happy conversation tomorrow. :)
>
>    
Tomorrow then!

Patrick

> Kind regards,
>
> 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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.