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?


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]
m: +1-510-435-8234
skype: kcoylenet/+1-510-984-3600