Ralph, I think this is moving into the territory of "transcription vs. LOD" that has been discussed here, or "document vs. data." Or even "things vs. strings." I like the idea of viewing it as "fingerprints" - kind of extended incipits, if you will. And your point that it isn't either/or is very important. We can have both transcribed "fingerprints" and URIs for things. Something else that I meant to mention in response to Lars' post, but still can't quite put into words: do all of our pointers have to be 99.99% guaranteed correct? That's the approach we take today (or pretend to), but in a "big data" world, it is possible to get close to truth even when some data are wrong. If a few "London (Ontario)"s get the URI for London, UK, does that invalidate the entire world of bibliographic data? Can the whole have a truthfulness that individual statements do not? Can we use data analysis to resolve some of these problems? kc On 8/15/14, 11:25 AM, LeVan,Ralph wrote: > > We collect metadata for a lot of reasons. One of those reasons is to > allow the holder of a book to match that book to catalog records. "Is > the description here actually for the book I have?" The holder of the > book only has access to the "fingerprints" on the body for making an > identification. The publishing statement is one of those > fingerprints. If we make it go away and replace it with a pointer to > an authority record, we've lost the connection between the book in > hand and the description of that book. > > Might it make sense to separate those descriptive practices? Might we > have a "fingerprints" section in a manifestation description? If we > capture those few unique fingerprints that the book holder has access > to and separate them in our description from the authority > descriptions, might we not make both processes simpler? Let's have a > fingerprint with the publishing statement from the book **and** a > pointer to a publisher **and** (if possible) a pointer to a > publication place. > > I think we've spent a lot of time trying to conflate two different > (but very real) problems just because they were conflated in MARC/AACR2. > > Ralph > -- Karen Coyle [log in to unmask] http://kcoyle.net m: +1-510-435-8234 skype: kcoylenet/+1-510-984-3600