 |
 |
I'm with ecorrado on this one, with the caveat that if you insist on putting a specific markup into your MARC -- and, boy, do the ROI analysis *very* carefully before jumping in -- you should probably stick the marked-up data in as a copy in a 9xx or somesuch. Leave the original value alone, and mirror it in a well-specified place for display purposes. If that's not an option, make the HTML as unintrusive as possible (e.g., keep white space, punctuation, and line breaks where you need them) so algorithmic removal of the markup is easy. On Tue, Jun 23, 2009 at 10:17 AM, Edward M. Corrado <[log in to unmask]>wrote: > I agree with everyone that has said embedding HTML in MARC records is bad > in theory, but sometimes you might not have a better option to serve your > community. I say do what you need to do to get your users to where they have > to go until we have better systems. The one caveat I'd point out if you do > this is to make sure you have an exit strategy (and test it). With some > ILSs, as long as you are consistent, you can easily export MARC records, use > some sort of script to edit them, and then reload them. Yes, in a perfect > world this would be bad, but alas, the library world is not perfect. > > Edward > > > Jonathan Rochkind wrote: > >> There are things you'd want to do with data in a MARC record _other_ than >> display it in HTML. Maybe you want to send it to someone in email, or a txt >> message. Embedding html in your marc is going to make this more difficult >> than it should be. >> >> Alexander Johannesen wrote: >> >>> Hiya, >>> >>> I guess I'm the one who's got to step up to the self-slaughtering >>> altar, but the fact that a lot of our systems break or don't know how >>> to handle HTML is despicable. I'm sure you guys are familiar with RSS >>> / Atom, and because in there we *expect* HTML and therefore make sure >>> our back-ends can grok it, it enhances the meta data *greatly*. >>> >>> Don't think for a second that purity of the data format in any shape >>> or form is the definition of its usefulness. Mixed content models >>> might be complex to work with, but their value is immense. I can fully >>> understand *why* people say "don't do it", because, yes, it ups the >>> complexity, and perhaps with these dinosaur technologies like MARC and >>> our ILS's breaking under the pressure of more modern technologies >>> enforces it, I don't think we should shun it because of it. >>> >>> If your back-end can't grok HTML, I'd suggest you fix it immediately! >>> If your ILS chokes on XML and / or HTML snippets, I suggest you >>> replace it. You seriously shouldn't allow this rigidity into your >>> infra-structure, and it's depressing to watch how we as complex users >>> of MARC don't dare to extend it to become a format that does what it >>> should and need to do. >>> >>> Even *if* HTML in MARC records probably is a bad idea. >>> >>> >>> Regards, >>> >>> Alex >>> -- >>> Project Wrangler, SOA, Information Alchemist, UX, RESTafarian, Topic >>> Maps >>> --- http://shelter.nu/blog/---------------------------------------------- >>> ------------------ http://www.google.com/profiles/alexander.johannesen--- >>> >>> >>> >> -- Bill Dueber Library Systems Programmer University of Michigan Library