Print

Print


On 3/31/15 10:21 AM, James Weinheimer wrote:
> On 3/30/2015 9:46 PM, Karen Coyle wrote:
>> (Note to JimW: Before you come back with some argument using MARCXML,
>> please check the MARCXML documentation. MARCXML has NO flexibility
>> compared to ISO 2709, and that is by design.)
>
> I also find Ron's analogy interesting, and I am still considering it. 
> But concerning the convention that MARCXML has NO flexibility 
> vis-a-vis ISO2709, that is really not much of an argument. I assume 
> this means the idea of "roundtrippability" of MARCXML, i.e. that 
> MARCXML must be able to create normal MARC21/ISO2709 records.
>

No, please read the documentation. MARCXML is a serialization of ISO 
2709 -- has nothing to do with content, and nothing to do with MARC21. 
Now, some other bibliographic XML format could be interesting, but 
please please please read the documentation and stop posting 
misinformation about MARCXML.

kc

> Anybody can avoid that with a wave of the hand. There is no immutable 
> "law of roundtrippability"--to my knowledge, there are no "MARC Storm 
> Troopers" who will break down your door in the middle of the night to 
> drag you off to their lair if you have the effontery to actually break 
> that "law". Nobody has to sign a contract that says you will be sued 
> if you don't follow "roundtrippability".
>
> Roundtrippability is no more than a convention. Developers are always 
> pushing the limits of such conventions. I'm glad they do. If they 
> always just followed what they were "supposed to do" and be "correct", 
> we would probably not have moved beyond the Gopher network.
>
> But what are the consequences of breaking roundtrippability? The 
> consequence is that anything created that is not roundtrippabile (an 
> awful word by the way!) cannot be input into our conventional ILS that 
> ingests only ISO2709 records. Although that happens every day in the 
> web world, for libraries it would be a tremendous step into the 
> unknown. Still, everybody knows this must happen inevitably sooner or 
> later and I am sure that many developers would only reply that it 
> would be much better sooner rather than later.
>
> If somebody wants to convert MARCXML in whatever ways they want, 
> nothing will happen to them. They'll be fine. They won't be kicked out 
> of the library profession. They won't be punished in any way. In fact, 
> if someone would make something good from MARCXML, they would--and 
> should--be applauded. This has been the case for a long, long time. 
> True, MARCXML can be difficult to work with, but it still *can* be 
> worked with if people know the schema (library developers). There has 
> been more than enough time to do so. But, many (catalogers especially) 
> have been convinced that we are stuck where we are because everything 
> must change first: formats, rules, and so on if libraries are to 
> create anything that is really new. And therefore, everyone is 
> supposed to wait how many *more* years before anything really 
> innovative can be done? This in spite of what each of us can see with 
> our own eyes: there are many bibliographic-type projects out there 
> now--right now--that really are doing new things. And they are doing 
> it with much worse formats and information than we have.
>
> Once again, I emphasize that am not trying to place blame or anything 
> of the sort. I repeat that I am *for* the RDF/Bibframe project. My 
> initial post was simply to alert catalogers (primarily) not to expect 
> anything anytime soon. And just a bit of the why.
>
> James Weinheimer [log in to unmask]
> First Thus http://blog.jweinheimer.net
> First Thus Facebook Page https://www.facebook.com/FirstThus
> Personal Facebook Page https://www.facebook.com/james.weinheimer.35
> Google+ https://plus.google.com/u/0/+JamesWeinheimer
> Cooperative Cataloging Rules 
> http://sites.google.com/site/opencatalogingrules/
> Cataloging Matters Podcasts 
> http://blog.jweinheimer.net/cataloging-matters-podcasts
> The Library Herald http://libnews.jweinheimer.net/
>
> [delay +30 days]

-- 
Karen Coyle
[log in to unmask] http://kcoyle.net
m: +1-510-435-8234
skype: kcoylenet/+1-510-984-3600