Re: After MARC...MODS?

Staying with the MARC / ISO2709 notation does us few favors with personal names. 
The MARC+AACR2 implementation of naming makes it very difficult to distinguish between the various "Smith, John" possibilities without referencing an authority file. If we're referencing an authority file anyway, why not take the next step?

This notation: "<name>Smith, John</name>" from "<bag1>" could be either:

<bag1>
<surnomen>Smith</surnomen>
<praenomen>John</praenomen>
</bag1>

Or

<bag1>
<personalname>
<reference1>Cloud-based Personal Names Authority File1 ID</reference1>
<reference2>Cloud-based Personal Names Authority File2 ID</reference2>
</personalname>
</bag1>

(there may be potential problems with these Anglo-centric naming conventions)

Continuing the theme, each work in a "local" catalog could be referenced to a Cloud-based Works Authority File, expand this out to all the common facts about a work or expression, etc. 

Going beyond that, then, the "local" item record (a.k.a. the inventory record) becomes a bucket of references attached to a local inventory control ID - where the ID is the Primary Key. The ID and its associated Foreign Keys are all the inventory system needs to track/control item circulation, just make the circ client a little smarter & have it pull in any necessary details from the cloud-based authority files (which means we could switch to an inexpensive, by comparison, off-the-shelf inventory system, similar to those used by Wal-Mart or any other retailer with automated checkout).

Discoverability becomes a query against a separate, large, common index (of whatever descriptive components required/desired plus a location identifier), which allows the searcher to learn whether the item is in the local library or must be requested from afar.

Local notes and local subject headings could be incorporated in the common index (perhaps keyed to a location identifier for "special snowflake-ness" if practical/desired) which would enrich the discoverability aspects of the ultimate work/expression/item.

I'm not saying MARC is bad; however, I am suggesting the current Local-ILS implementation of MARC may be an evolutionary dead-end.

-Aaron
:-)'

> -----Original Message-----
> From: Next generation catalogs for libraries
> [mailto:NGC4LIB_at_LISTSERV.ND.EDU] On Behalf Of Weinheimer Jim
> Sent: Tuesday, April 20, 2010 6:32 AM
> To: NGC4LIB_at_LISTSERV.ND.EDU
> Subject: Re: [NGC4LIB] After MARC...MODS?
<snip>
> What I meant by inflexible is the trouble MARC has for importing
> information from other places. For example, if the above record had a
> lot of analytics, with flexible formats, they could be more easily
> imported, e.g. (making this up)
> =505
> <bag1>
> <name>Smith, John</name>
> <title>Act I of All's well that ends well</title>
> <note>Originally presented as a paper at...</note>
> </bag1>
> <bag2>
> <name>Smith, Susan</name>
> <title>Act I, scene 2 of All's well that ends well</title>
> <note>Originally published in ...</note>
> </bag2>
> 
> When we add to this scenario information feeding in from all over, such
> as the example of John Smith's form of name being taken through a URI,
> or imported links to the conference, or other possibilities such as RSS
> feed updates, and I can't imagine what else right now, MARC has
> problems. The above example cannot be done with the current MARC
> format.
</snip>