Subject: [CODE4LIB] HTML mark-up in MARC records

From: "Doran, Michael D" <[email-masked]>
Date: Sun, 21 Jun 2009 15:12:55 -0500

Is anybody else embedding HTML mark-up code in MARC records [1]?  We're currently including an "<img>" tag in some MARC Holdings records in the 856z [2].   I'm inclined to think that HTML mark-up does not belong anywhere in MARC records, but am looking for other opinions (preferably with the reasoning behind the opinions), both pro and con.  

I'm asking on code4lib as well as the voyager-l list in order to get a mix of ILS-specific and ILS-agnostic opinions (I'm not on any cataloging lists, or would probably ask there, too).  I tried googling this topic, but couldn't find anything of consequence; so if I've missed something there, and you could point me to it, I'd be obliged.

-- Michael

[1] http://en.wikipedia.org/wiki/HTML

[2] http://www.loc.gov/marc/holdings/hd856.html
      
# Michael Doran, Systems Librarian
# University of Texas at Arlington
# 817-272-5326 office
# 817-688-1926 mobile
# [email-masked]
# http://rocky.uta.edu/doran/

---

From: Walter Lewis <[email-masked]>
Date: Sun, 21 Jun 2009 16:47:08 -0400

> Is anybody else embedding HTML mark-up code in MARC records [1]?  We're currently including an "<img>" tag in some MARC Holdings records in the 856z [2].   I'm inclined to think that HTML mark-up d…
One of the things I found in some specific instances where I was 
generating Marc-like records on the fly from records that could have 
embedded HTML (i.e. MARBI marc community output) was that a variety of 
the targets that could read the data didn't know what to do with the 
<tags> and escaped them before passing them to the web client.  In 
short, consider the downstream partners who may try and render the HTML 
and what interfaces they are using.  Not everyone views the record via a 
browser ... :)

Walter Lewis

---

From: "Mark A. Matienzo" <[email-masked]>
Date: Sun, 21 Jun 2009 16:48:43 -0400

I strongly oppose using any HTML mark-up in MARC records - this should
be the domain of the OPAC to render things appropriately. URIs for
images are fine, but is subfield z appropriate as well? I'd be
inclined to use a subfield 9 since it's purposely designed for local
use.

Mark A. Matienzo
Applications Developer, Digital Experience Group
The New York Public Library

---

From: "Doran, Michael D" <[email-masked]>
Date: Sun, 21 Jun 2009 15:49:57 -0500

# Michael Doran, Systems Librarian
# University of Texas at Arlington
# 817-272-5326 office
# 817-688-1926 mobile
# [email-masked]
# http://rocky.uta.edu/doran/
________________________________________
From: Code for Libraries [[email-masked]] On Behalf Of Walter Lewis [[email-masked]]
Sent: Sunday, June 21, 2009 3:47 PM
To: [email-masked]
Subject: Re: [CODE4LIB] HTML mark-up in MARC records

Walter Lewis

---

From: Jonathan Rochkind <[email-masked]>
Date: Sun, 21 Jun 2009 16:52:05 -0400

Yeah, if I was writing code to display MARC, I think the _right_ thing to do would be to escape anything I was displaying, because I'd assume it was NOT html, but might have < or > chars in it, etc. 

I don't think HTML tags belong in MARC, that seems like a bad idea to me.  Unless there was a way to encode that a given field was html -- but even THAT seems like a bad idea to me. What is html display tags doing in marc data?  That's not what it's for.  One example of a decent way to put things that can be _transformed_ into html in MARC is the 856$y subfield for specifying a display label.  If you can find a way to put the url to an image in a particular subfield of your MFHD designated (even locally) for such, that would be the right way to do it -- but odds are you can't get your OPAC to do anything with that anyway.  But trying to put weird inappropriate things in MARC in order to cater to the idiosyncratic disfunctional presentation software you happen to be stuck with -- leads to bad unpredictable marc you're going to regret later, as your data WILL outlast the particular software you happen to be using at present to display it. 

Jonathan
Sent: Sunday, June 21, 2009 4:47 PM

Walter Lewis

---

From: stuart yeates <[email-masked]>
Date: Mon, 22 Jun 2009 09:05:15 +1200

> Is anybody else embedding HTML mark-up code in MARC records [1]?  We're currently including an "<img>" tag in some MARC Holdings records in the 856z [2].   I'm inclined to think that HTML mark-up d…

A couple of quick questions:

(1) When you say "HTML" which version of HTML are you using?
(2) What tool are you using to validate the HTML inside the MARC?
(3) Since HTML can use character encodings that MARC doesn't understand, 
how are you escaping the non-ASCII characters in the HTML?

cheers
stuart
-- 
Stuart Yeates
http://www.nzetc.org/       New Zealand Electronic Text Centre
http://researcharchive.vuw.ac.nz/     Institutional Repository

---

From: "Doran, Michael D" <[email-masked]>
Date: Sun, 21 Jun 2009 17:08:53 -0500

Hi Stuart,

> A couple of quick questions:

I'd be glad to answer, but I suspect these really only have relevance *after* the main issue ("Is embedding HTML mark-up in MARC records a good/bad idea?") is decided.  ;-)

> (1) When you say "HTML" which version of HTML are you using?

For the HTML markup in the record, there's obviously no version explicitly specified.  Some <img> tags have an end tag (i.e. <img src="URL" />), so could be said to conform to XHTML 1.0, others have no end tag, so are generic HTML.  The ILS in question declared pages to be "HTML 4.0 Transitional" in older versions of the online catalog but HTML standards compliance was wishful thinking.  The current version declares pages to be "HTML 4.01 Transitional" and comes a lot closer to conforming.

This does bring up the issue, though, of the potential for a mis-match in conformation to a  declared DOCTYPE between the HTML mark-up in the record, and the online opac's HTML mark-up. 

> (2) What tool are you using to validate the HTML inside the MARC?

None that I am aware of.  (Note I'm not in the cataloging department, so am not familiar with all their workflow.)

> (3) Since HTML can use character encodings that MARC doesn't understand, how are you escaping the non-ASCII characters in the HTML?

I'm not sure what you are asking here.  I'm not aware of any HTML elements and/or attributes that contain non-ASCII characters.  Perhaps you are referring to data (or perhaps attribute values) rather than to the HTML mark-up code.  Our MARC records are encoded in Unicode UTF-8, so potentially any character can be represented.  For display of the data on the web, the online catalog is declaring that character set in a meta tag: <META http-equiv="Content-Type" content="text/html; charset=UTF-8">.

-- Michael

# Michael Doran, Systems Librarian
# University of Texas at Arlington
# 817-272-5326 office
# 817-688-1926 mobile
# [email-masked]
# http://rocky.uta.edu/doran/
________________________________________
From: Code for Libraries [[email-masked]] On Behalf Of stuart yeates [[email-masked]]
Sent: Sunday, June 21, 2009 4:05 PM
To: [email-masked]
Subject: Re: [CODE4LIB] HTML mark-up in MARC records

cheers
stuart

---

From: Mark Jordan <[email-masked]>
Date: Sun, 21 Jun 2009 15:10:39 -0700

----- "Walter Lewis" <[email-masked]> wrote:

  In 
> and what interfaces they are using.  Not everyone views the record via

One downstream client that embedded HTML-in-MARC will almost certainly cause grief for is an OAI-PMH harvester. Unless your OAI data provider CDATAs this markup, the exposed XML will likely be invalid or at the very least un-namespaced. 

Same goes for MARC records emitted by unapi/ATOM/etc., I would imagine.

Mark

---

From: Danielle Plumer <[email-masked]>
Date: Mon, 22 Jun 2009 10:27:51 -0500

Michael,

For institutions that catalog digital objects in MARC or link to digital surrogates as UT Arlington does, my recommendation is to use the 856 as follows:

856 41 $u http://www.uta.edu/library/ccon/images/thumbs/00384Thumb.jpg $3 thumbnail image
856 41 $u http://www.uta.edu/library/ccon/mrsid_images/ccon/00384.sid $3 access image
856 42 $u http://libraries.uta.edu/ccon/scripts/ShowMap.asp?accession=00384 $3 Cartographic Connections web site

If there were a finding aid, it would go in as

856 42 $u http://library.uta.edu/findingAids/maps.jsp $3 finding aid

There have been conservations on the AUTOCAT list about the subfield 3; there's no controlled vocabulary or even best practices for how to use it, which makes it very difficult to use as a guide to what exactly you're linking to. We're working on a formal set of best practices for digitization projects in Texas that will include a recommendation similar to this.

From a set of 856s like this, I can create a stylesheet to display the thumbnail image and link out to the website appropriately in our statewide image search tool Texas Heritage Online. I access UT Arlington's collections over Z39.50, btw -- see http://www.texasheritageonline.org/search.tkl?focus=target-utar-ccon.tkl&cclquery=map&offset=1. 

Having HTML tags in the MARC is unnecessary, and might break things in "normal" catalog displays. What I need most is consistency so that I don't have to figure out every possible variation for every possible system, which gets a bit old.

Danielle Cunniff Plumer, Coordinator
Texas Heritage Digitization Initiative
Texas State Library and Archives Commission
512.463.5852 (phone) / 512.936.2306 (fax)
[email-masked]

-----Original Message-----
From: Code for Libraries [mailto:[email-masked]]On Behalf Of
Doran, Michael D
Sent: Sunday, June 21, 2009 5:09 PM
To: [email-masked]
Subject: Re: [CODE4LIB] HTML mark-up in MARC records

Hi Stuart,

-- Michael

cheers
stuart

---

From: "Cloutman, David" <[email-masked]>
Date: Mon, 22 Jun 2009 14:53:45 -0700

From the perspective of a programmer, rather than a cataloguer, my opinion is firmly no, HTML does not belong in your MARC records. 

In application development, general best practice is to separate information systems into layers, splitting data from "business logic" and "presentation logic". MARC stores data, and HTML belongs to presentation. Though it may sound like a good idea today to put HTML into a MARC record, that tag may be meaningless down the road when some other technology is used to present your record data. If you wish to present data in HTML, you are much better off leaving the HTML out of your MARC, and allowing the application to generate tags.

-----Original Message-----
From: Code for Libraries on behalf of Doran, Michael D
Sent: Sun 6/21/2009 1:12 PM
To: [email-masked]
Subject: [CODE4LIB] HTML mark-up in MARC records

-- Michael

      

Email Disclaimer: http://www.co.marin.ca.us/nav/misc/EmailDisclaimer.cfm

---

From: Eric Lease Morgan <[email-masked]>
Date: Mon, 22 Jun 2009 18:19:17 -0400

On Jun 22, 2009, at 5:53 PM, Cloutman, David wrote:

> From the perspective of a programmer, rather than a cataloguer, my  
> opinion is firmly no, HTML does not belong in your MARC records.
>
> In application development, general best practice is to separate  
> information systems into layers, splitting data from "business  
> logic" and "presentation logic". MARC stores data, and HTML belongs  
> to presentation. Though it may sound like a good idea today to put  
> HTML into a MARC record, that tag may be meaningless down the road  
> when some other technology is used to present your record data. If  
> you wish to present data in HTML, you are much better off leaving  
> the HTML out of your MARC, and allowing the application to generate  
> tags.

I whole-heartedly concur, and I could not hardly have said it any  
better than David. Adding mark-up to a data structure like that only  
confuses the issue and is asking for trouble down the road.

-- 
Eric Lease Morgan

---

From: Alexander Johannesen <[email-masked]>
Date: Tue, 23 Jun 2009 09:17:28 +1000

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 ---

---

From: Kyle Banerjee <[email-masked]>
Date: Mon, 22 Jun 2009 16:26:38 -0700

> or form is the definition of its usefulness.

We'd be screwed if that was the case. ISBD punctuation has been in the
MARC record from the very beginning. Theoretically, it should be
totally unnecessary since the data is already structured....

kyle

---

From: Roy Tennant <[email-masked]>
Date: Mon, 22 Jun 2009 21:22:50 -0700

> Even *if* HTML in MARC records probably is a bad idea.

Yes, it's such a bad idea it's hard to know where to begin. I'd like to
thank Kyle Banerjee for bringing up ISBD. This is like the HTML of the 60's
in the sense that now MARC is saddled with "markup" from the 60s that we
have ALL KINDS of trouble dealing with going forward. If we've learned
anything at all, it should be to not mix presentation with data. Let
succeeding generations (and us too!) decide how they wish to depict the data
-- but don't saddle them (and us) with the depictions of preceding
generations.
Roy

---

From: Casey Bisson <[email-masked]>
Date: Tue, 23 Jun 2009 09:39:21 -0400

The mistake here is presuming that (X)HTML coded data isn't (or can't  
be) data.

On Jun 23, 2009, at 12:22 AM, Roy Tennant wrote:

> If we've learned anything at all, it should be to not mix  
> presentation with data.

---

From: Ross Singer <[email-masked]>
Date: Tue, 23 Jun 2009 10:00:09 -0400

On Tue, Jun 23, 2009 at 9:39 AM, Casey Bisson <[email-masked]> wrote:

> The mistake here is presuming that (X)HTML coded data isn't (or can't be)
> data.
>

I think it's a greater mistake to assume that it will be.

We are talking about putting semantics into a structured data source (by
people who are trained in both the data format in particular and the tools
to input data into it), why introduce another data format (out of context, I
might add -- we're only talking about a single tag) which is much more
likely to be adulterated by human input and the fallacies that come with
being human?

A semantic XHTML serialization of data is very different than ad-hoc usage
of HTML for a local need.

-Ross.

---

From: Jonathan Rochkind <[email-masked]>
Date: Tue, 23 Jun 2009 10:02:57 -0400

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.

---

From: "Edward M. Corrado" <[email-masked]>
Date: Tue, 23 Jun 2009 10:17:08 -0400

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:
> 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.
>
>> --- http://shelter.nu/blog/ 
>> ----------------------------------------------
>> ------------------ 
>> http://www.google.com/profiles/alexander.johannesen ---
>>
>>

---

From: Bill Dueber <[email-masked]>
Date: Tue, 23 Jun 2009 10:51:21 -0400

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 <[email-masked]>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.
>>
>>> --- http://shelter.nu/blog/----------------------------------------------
>>> ------------------ http://www.google.com/profiles/alexander.johannesen---
>>>
>>>
>>>
>>

-- 
Bill Dueber
Library Systems Programmer
University of Michigan Library

---

From: Ere Maijala <[email-masked]>
Date: Wed, 24 Jun 2009 11:21:39 +0300

Mark Jordan wrote:
>> short, consider the downstream partners who may try and render the 
>> HTML and what interfaces they are using.  Not everyone views the
>> record via a browser ... :)
>> 
> 
> One downstream client that embedded HTML-in-MARC will almost
> certainly cause grief for is an OAI-PMH harvester. Unless your OAI
> data provider CDATAs this markup, the exposed XML will likely be
> invalid or at the very least un-namespaced.
> 

That shouldn't be a problem as any sane OAI-PMH provider, unAPI or ATOM 
serializer would escape the contents. Things that resemble HTML tags 
could be present in MARC records without any HTML-in-MARC too.

That's, by the way, also a problem if you start treating MARC field 
contents as HTML. Here's a real-world example author field:

Babin, Malte-Ludolf.11a<orgolh> - <umil>

--Ere

---

From: Jonathan Rochkind <[email-masked]>
Date: Wed, 24 Jun 2009 10:33:58 -0400

> could be present in MARC records without any HTML-in-MARC too.
Sure, and then, if you have html tags in your marc, that system doing 
the re-use is going to present content to users with escaped HTML in it, 
which isn't desirable either!

You might think, oh, nobody is going to be re-using this particular marc 
field, but then a few years down the line, the environment changes, and 
you notice too late that you've got this big headache to deal with. This 
is an experience many of us have had over and over with our decades old 
MARC -- MARC written for a particular very specific environment, rather 
than as good general purpose data, causing us trouble when the 
environment has changed greatly but our data remains.

---

From: Ere Maijala <[email-masked]>
Date: Thu, 25 Jun 2009 14:23:51 +0300

> which isn't desirable either!

How the content is stored in the transport format is separate from how 
it is used. Whatever the re-using system does is not related to how the 
data was transferred to it. If it extracts the stuff from the XML, it 
will of course unescape the content, but what happens after that is up 
to the system and unrelated to the transport mechanism. So here is an 
example of the whole process:

MARC with embedded HTML
->
OAI-PMH provider escapes the MARC in some XML format
->
OAI-PMH harvester (the re-using system) unescapes the data from the XML 
format
->
Something is done with the data

It's the same as if the source system stores the data internally in 
MARCXML. The content must be escaped so that it can be stored in MARCXML 
and doesn't mess up the markup, but when the uses the data e.g. for 
display, it's first retrieved from XML and unescaped, and massaged to 
the desired display format only after that. If you use DOM to do the XML 
manipulation, all this will happen automatically. You just write and 
read strings and DOM manipulation takes care of escaping and unescaping.

You could substitute XML with e.g. Base64 encoding if it makes thinking 
about this stuff easier. For instance email clients often send binary 
files in Base64, but it doesn't mean the file is ruined, as the 
receiving email client can decode it back to the original binary.

--Ere

---

From: Jon Gorman <[email-masked]>
Date: Thu, 25 Jun 2009 08:23:41 -0500

> about this stuff easier. For instance email clients often send binary files
> in Base64, but it doesn't mean the file is ruined, as the receiving email
> client can decode it back to the original binary.

A bit of an ironic statement, considering a regular, constant
complaint on several library-related mailing lists I'm on is that
emails are coming in "garbled" or need to be sent again in "plain
text".   Without fail it's because the person is using a client that
won't or can't deal with Base64.  Yes, silly this day and age.

Perhaps I'm just jaded from working into libraries for too long but
your examples assume some logical consistent control through the
process of dealing with MARC data.

Let's think of this scenario instead:
You're using your vendor's ILS system.  You stick some html tags into
a record.  The vendor's ILS does some different stuff with it like
indexing it, storing the complete record for later retrieval, and
pulling data in the record into a semi-normalized scheme in a
database.  Now the librarians that have just enough training to do
some reports for these systems start running them via access and start
shifting the data around in Access, Exce,l and Word.  Then a little
while later they start raising alarms because of either:  they see the
markup in the record and wonder what's happening and how to remove it
or one of those tools treats that area as text, another as xml
content, and somewhere along the way it gets messed up.

The above is not really all that uncommon of a scenario.

Or how about this scenario:
You add some html internally to a MARC record.  You then add it to
your ILS system.  A few years later you go to export and decide to do
it in MARCXML.  Unknown to you, the ILS doesn't do a sane translation
process, but rather rebuilds the MARCXML from information in the
database that was put there by the original MARC.  The code is
horribly setup and hackish and certain fields do not bother to escape
what it's retrieving from the record.  You then go to import to your
new ILS, which validates the MARCXML.  It of course now croaks because
you have something like
<marc:subfield code="a"><div class="foo">pretty</div>.

Would you count on having someone on the staff who will be able to fix
those MARCXML files?  Or did you have someone like that and they
burned out?  How long before the support contract on your old ILS
forces you to abandon it?

Plus the fact there's still unresolved questions.  Let's take RSS as
an example as a format that has been abused by html in the past.  If
you find "html" in RSS, you can't be sure if it valid or well-formed.
Frequently there's no way to know what version of html it is.  Yes, in
the end you can just throw it at a html parser or a browser and hope
for the best, but we have to consider the input mechanisms here. Are
folks going to be entering the html by hand?  Are there going to be
some sort of macros?  Some sort of batch change process?  Each have
different level of risks for having bad html.  How much extra
processing are you going to want to do for each record each time you
might end up displaying it?  What to do with a mistake?  Let your
parser determine or their browser?

It's great to say we should simply re-write our tools, but many of us
work with tools supplied by vendors.  We may be trying to move to more
open tools and the like but ultimately we're constrained by what our
upper managements dictate.

There's both practical reasons (untrustworthy systems) and more
abstract reasons (how to we communicate which version?  namespaces?
etc) issues at play here.  Ultimately I do agree that if it could not
be avoided to try putting in the html into the record itself.  A gain
of better usability and functionality over a couple of years is
probably worth it as the chance of a large issue later on is quite
small.  (Higher chance of small issues though).

I mainly sent out this email though because I don't think the folks
who have been pointing out issues are confused.  It's not that we
don't understand that it should be able to "round-trip" or that we
haven't played around with html in other data formats.  I think we've
used enough software in the library would to not trust all the layers
will work as they should.

Jon Gorman

---

From: Jonathan Rochkind <[email-masked]>
Date: Thu, 25 Jun 2009 09:56:45 -0400

But here's my point. 

There is no way for a consumer of MARC records to know if the MARC 
records contain HTML or not.  If a downstream consumer wants to display 
MARC in an html environment, the consumer can either assume they contain 
html, and then end up displaying MARC _wrong_ if it has has html special 
chars like < or > but does not have html. Or it can assume it does 
_not_have HTML, and end up displaying escaped html tags to the user if 
it really DOES have html.  This really applies no matter what 
presentation format the downstream consumer wants to display in. Plain 
text?  Assume it is html, and strip out html tags, potentially 
accidentally stripping out actual information if it wasn't html but 
contained html special chars. Or assume it's not html and just plain 
text, and just display it, and show the user html tags.

There's no way for a downstream consumer of MARC records to know if data 
is in html or just plain text.  In general, I think this is becuase the 
assumption is it's always just plain text.  If you start putting html in 
there, there's no way for a downstream consumer to predict whether it's 
going to be html or not, because that's not part of the MARC standard to 
advertise that, so there's no way for a downstream consumer to reliably 
display it correctly.  You've put html in counting on your current local 
system being specifically configured to expect html in certain MARC 
fields. Fine. But as soon as you start distributing that MARC to 
downstream consumers, you've made things awfully confusing and 
unpredictable.

Jonathan

---

From: Tim Hodson <[email-masked]>
Date: Thu, 25 Jun 2009 21:22:50 +0100

Michael,

A lot of the discussion so far seems to have missed the opportunity to
find out exactly what you are hoping to accomplish. (unless I missed
that post :) ). And to perhaps suggest alternative ways of doing that.

My first question is: What is the image an image of?

This is shortly followed by several more....
What is the name of the image (perhaps it is an ISBN)?
Where is the actual image going to be stored?
Does it actually make any sense to embed the URI of an image in the data?
What happens if the image name changes, or becomes unavailable?
What happens if the marc record is exported/consumed by another system?
(setting aside completey the issue of markup within markup discussed
elswhere in this thread)

If this is simply a way to get an image into the catalogue display, I
can think that there might be better ways.
For example Juice [1] which could allow you to dynamically load an
image (from a suitably maintained source) based on an identifier
somewhere within the page.

Best,
Tim

[1] http://code.google.com/p/juice-project/

----------------------------------------------
Tim Hodson
http://informationtakesover.co.uk

---

From: "Doran, Michael D" <[email-masked]>
Date: Thu, 25 Jun 2009 18:00:07 -0500

Hi Tim,

> find out exactly what you are hoping to accomplish.

The discussion itself was what I was looking for.  I'm actually fairly aware of the problems inherent in this practice (although not nearly as eloquent nor as thorough as some of the thread responders).  What I was hoping to accomplish was to convince some cataloging decision makers here that our current practice of including HTML mark-up in MARC records is not a good idea and that we should stop doing it.  I was looking to the discussion to either buttress my arguments with expert opinion or get a real convincing reason why my rationale was not valid.

> My first question is: What is the image an image of?

It's a bit ironic perhaps, but most of the images are essentially *text* -- e.g. the words "UTA Plus OffCampus" in a gif [1].

> Where is the actual image going to be stored?

The image example above was stored on our OPAC server.  With a new version of the OPAC, the path to images changed, and 250,000+ holdings records needed to be edited.  This new OPAC version is more flexible and it would probably be possible to add the images we currently have encoded via HTML tags in the MARC holdings record, to the OPAC record view on the fly.

-- Michael

[1] http://pulse.uta.edu/images/offcampPulse.gif

> From: Code for Libraries [mailto:[email-masked]] On 
> Behalf Of Tim Hodson
> Sent: Thursday, June 25, 2009 3:23 PM
> > Is anybody else embedding HTML mark-up code in MARC records 
> [1]?  We're currently including an "<img>" tag in some MARC 
> Holdings records in the 856z [2].   I'm inclined to think 
> that HTML mark-up does not belong anywhere in MARC records, 
> but am looking for other opinions (preferably with the 
> reasoning behind the opinions), both pro and con.
> >
> > I'm asking on code4lib as well as the voyager-l list in 
> order to get a mix of ILS-specific and ILS-agnostic opinions 
> (I'm not on any cataloging lists, or would probably ask 
> there, too).  I tried googling this topic, but couldn't find 
> anything of consequence; so if I've missed something there, 
> and you could point me to it, I'd be obliged.
> >
> > -- Michael
> >

---

From: "Cloutman, David" <[email-masked]>
Date: Thu, 25 Jun 2009 16:35:18 -0700

> It's a bit ironic perhaps, but most of the images are essentially
*text* -- e.g. the words "UTA Plus OffCampus" in a gif [1].

I can see why you are trying to talk your catalogers out of this one. I
think my head is going to explode thinking about it. Best of luck to
you.

---
David Cloutman <[email-masked]>
Electronic Services Librarian
Marin County Free Library 

-----Original Message-----
From: Code for Libraries [mailto:[email-masked]] On Behalf Of
Doran, Michael D
Sent: Thursday, June 25, 2009 4:00 PM
To: [email-masked]
Subject: Re: [CODE4LIB] HTML mark-up in MARC records

---

From: Ere Maijala <[email-masked]>
Date: Fri, 26 Jun 2009 09:51:24 +0300

> won't or can't deal with Base64.  Yes, silly this day and age.

Well, yeah, of course the receiving party could be broken, but there's 
definitely all the information and rules it could use to decode the data.

> process of dealing with MARC data.

Not really, just some consistency in working with XML.

> content, and somewhere along the way it gets messed up.

I failed to make the statement that I definitely don't support adding 
HTML to MARC records (unless at least a clean and backwards-compatible 
way to do that is devised). My point was just that the transport 
mechanism is irrelevant.

> <marc:subfield code="a"><div class="foo">pretty</div>.

You're screwed then. You don't need embedded HTML to break it. For 
instance a simple < ("less than") character in a field would do. This is 
an example of very broken XML creation. I've done it myself too, but 
fixed it asap to avoid more embarrassment. All this, however, is not a 
useful argument in the HTML in MARC records debate.

> forces you to abandon it?

Ok, this is drifting off-topic, but if you have a way to get the 
original MARC records in ISO2709 format (or any other non-broken 
format), it's a very simple task to convert them to valid MARCXML.

> will work as they should.

And my response was to Jonathan simply trying to state that encoding the 
stuff in XML doesn't make a difference. I agree with you that there are 
interoperability issues, but there are also examples in the library 
world where stuff just works even when XML is involved, and the 
receiving party can get the data intact.

--Ere

---

From: Ere Maijala <[email-masked]>
Date: Fri, 26 Jun 2009 09:55:29 +0300

No argument here. Perhaps I misunderstood your previous message as it 
was related to Mark's message about OAI-PMH etc.

--Ere

---

From: Ere Maijala <[email-masked]>
Date: Fri, 26 Jun 2009 09:59:30 +0300

> receiving party can get the data intact.

Actually, it was my first message replying to Mark's message. I didn't 
mean to imply that Jonathan didn't know what he's talking about. Nor did 
  I mean to imply I'd support embedding HTML in MARC. Only that it 
wouldn't cause trouble for OAI-PMH etc. provided they handle XML properly.

--Ere

---

From: Tim Hodson <[email-masked]>
Date: Fri, 26 Jun 2009 08:44:36 +0100

Hi Michael,

I certainly hope you succeed in your persuasive efforts. :)

I would be thinking along the lines that if the image is mostly text,
and the text is obviously trying to convey some sort of availability
of an electronic version of the article/abstract etc, so why not
encode the AVAILABILITY in the marc record. perhaps in the 856.  This
would make the data far more portable and reusable, and would separate
the data from the view. It would also negate any need to put
potentially ugly/destructive/unpalatable/etc html in the marc record.

Less is more :)

Tim

---

From: Jonathan Rochkind <[email-masked]>
Date: Mon, 29 Jun 2009 11:28:52 -0400

I agree with Ere that XML isn't the real issue here, in understanding 
why embedding HTML in MARC is nevertheless something to be avoided if at 
all possible. :)