 |
 |
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. Jonathan > 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. > > kyle >