On 8/4/2011 3:33 PM, Karen Coyle wrote:
In general I am having a hard time understanding how we will treat these kinds of composite headings in any future data carrier. They seem to be somewhat idiosyncratic, in that what data gets added is up to the cataloger, depends on the context, and probably cannot be generated algorithmically.
I'm thinking these sorts of headings should essentially be treated as opaque identifiers -- they were meant to basically serve the purpose identifiers, thus adding more-or-less arbitrary ("some date you choose with meaning, your choice!") characters on the end to disambiguate, same as you'd add a more-or-less arbitrary path component on to the end of a URI to make sure it's unique, but expecting the finished URI string to be treated basically as an opaque identifier.
So if you're stumped, I'd suggest seeing if there's a way to punt and treat these kind of headings as single un-subfielded opaque identifiers (they're not URI's, they're 'local' identifiers, but they're a kind of identifier. Well, 'local' in the sense of local to a particular authority file, particular community, or sometimes actually particular local system).
Of course, that may cause it's own problems, if you just combine ALL uniform titles subfields into one big opaque 'identifier' string, might be losing useful semantic information that is in some of the other subfields. It's tricky, our legacy data is very legacy. (I don't know what that means, but I'm sticking to it.) So maybe just the subfields you have to punt on, don't worry about, just call em "disambiguating suffix" or "disambiguating date suffix" or something. Since that's all they are.
Either way, I think it's probably important and useful to conceptualize our legacy headings as legacy semi-opaque 'identifiers'. For instance, it's absolutely vital, to make use of this data with legacy systems, that once you've deconstructed these things down to semantic elements, the system is still able to reconstruct them into the exact literal combined string 'identifier'. So either your encoding has to somehow preserve order (perhaps there is an implicit order to each element, if the marc fields for these 'headings' work that way, I'm not sure) -- or perhaps there needs to be another 'heading' data element that will include the complete assembled heading string 'identifier', even though that is duplication of information.
