Print

Print


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:
[log in to unmask]" type="cite">

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