On 5/19/2011 2:33 PM, Kyle Banerjee wrote:
> However, what would be the use case for including them as you don't
> know how
> they'll be interpreted by the app that you hand the data to?
Only when the destination is an app you have complete control over too.
One use case I was idly turning over in my head lately. I export data
about my bibs from my ILS to Solr in Marc. But I am increasingly needing
to stuff 'local' data that doesn't fit into any Marc field in there too,
because I need it available at Solr indexing stage. Not concerned with
doing this in a 'standard' way, just need to get it in there SOMEHOW,
because Marc is all that makes it to my Solr indexer. (and it would be
somewhat complicated to change my pipeline to send a package that
includes Marc plus other metadata payloads, there are a bunch of pieces
in the pipeline that really want Marc-as-marc).
So one idea I had was encoding it as arbitrary key/value pairs in YAML,
and just sticking the YAML in a 9xx field.
But a newline is a significant character for YAML. I don't care about
this data being _meaningful_ to anyone other than my own custom local
destination, but I do care about leaving the Marc structurally legal
(especially because if its' not some of the individual elements of the
pipeline might choke on it or corrupt it).
Another different idea I was also thinking about: All of our MARC
'summaries' (520) show up in our interfaces as one giant paragraph. Even
when they are publisher back-of-the-book copy that was originally
multiple paragraphs. Sometimes a MARC record has the exact same text in
it as an Amazon description, but the Amazon description is a lot more
readable because it is rightly multiple paragraphs. If newlines were
legal in a 520, then a cataloger could preserve them --- systems that
just ignored it would continue to, no loss; but systems that wanted to
take account of it could, for instance by using HTML <BR> or <P> tags to
paragraph-ize on newlines before outputting to an HTML display. But not
if newlines aren't legal in a value, of course.
> I've seen
> people put HTML in certain fields to achieve a certain effect in catalogs,
> but this is a dodgy practice since it relies on the questionable assumption
> that the end application will just pass through whatever is sent.