Re: [libdb-develop] locations

[Morbus I. <mo...@di...>]

>At minimum, the ability to distinguish physical locations (.e.g
>archival holding locations) from electronic.  For electronic,
>citations require date accessed info.
>
>  Collection X, ABC Archive, Box 23, Folder 324
>
>...the collection info is actually a title associated with the isPartOf
>(or mods relatedItem "host") structure, so that's no big deal.  Beyond
>that, I actually have three further chunks of information.  But then
>... is the archive really a location, or should it be handled by some
>other structure?   Box and folder are two separate location
>designations, but then this starts to become blurred with another
>structure: "parts" in MODS, which represent things like page, volume
>and issue numbers.  Where's the conceptual line between a folder and an
>issue, after all?  Maybe a distinction between an, um, manifestation
>and an item??

Well, I'm not thinking of "location" as anything like "parts" of an
item. Sure, an article has a "location" within a magazine, but that's
not what I want LibDB's "location" to mean. Or rather, that's not what
I *intend* it to mean. In the current scheme, "location" solely means
"where an item is physically located" - a box, a shelf, a bookcase.

The current location scheme doesn't support hierarchies either, so
if you wanted to indicate multiple levels of granularity, it'd have
to be a single name ("Collection X, ABC Archive, Box 23, Folder 324")
mainly because the current assumption is that *one* item can only
have *one* location. Granted, we can go nuts with specifics:
"North America, United States, New Hampshire, Concord, 28 Thompson
St., Apt. A, Collection X, ABC Archive, Box 23, Folder 324" could
point to the exact same location as "Folder 324" (assuming I had
only one "Folder 324" in my collection).

I don't want, from the beginning, to overcomplicate what I'm doing.
I *really* need to say "mmkay, this is what I'm coding, and anything
extra will be dealt with later." Else the standard feeping creaturism
stuff happens: always building with never a release. With that in mind,
I'm not sure that 0.1.0, or even 0.2.0 and 0.3.0, is going to be usable
from an *electronic resource* point of view: for now, I'm strictly
focusing on physical assets, and even narrower, movies (and even
narrower, physical representations of movies, not encoded digital).

Still, I can't help but feel that an electronic resource should not
be labeled with a "location" but rather as having an identifier that
points to a location. This seems to be a core idea of the DOI project:
give an electronic resource an identifier, and DOI servers will take
that identifier and give you a location. Without further research (and
I'll heartily admit that I've NOT done heavy resource on cataloging
electronic assets), I'm inclined to say "an electronic resource has
an /identifier/ like a DOI or URI, and not a /location/".

-- 
Morbus Iff ( whooooooo's hoooouuuuuse? )
Technical: http://www.oreillynet.com/pub/au/779
Culture: http://www.disobey.com/ and http://www.gamegrene.com/
icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus