libdb-develop

Re: [libdb-develop] Don't Look At This Demo

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

Still plenty more to do (I've yet to address Bruce's Safari thing, and
I believe I've licked the mod_perl problems but have yet to implement
them), but another update of half-working code tonight.

The "add film" page hasn't changed in coding whatsoever:
http://disobey.com/noos/LibDB/dev/index.cgi?tmpl=add_film

But, I've started work on making "locations" actually do something
from a database integration point of view. You can see the list of
current locations here:

  http://disobey.com/noos/LibDB/dev/index.cgi?tmpl=locations

Nothing too surprising. That's the happy browsing interface.
The administrative interface, however, adds editing buttons:

  http://disobey.com/noos/LibDB/dev/admin.cgi?tmpl=locations

Clicking the little pencil icon thing will bring you to an
editing form, which actually works. You can go and edit existing
locations all you want, and you'll be informed of your success,
as well as be given the opportunity to re-edit your edits <g>.

I don't have a magic button (yet) for adding a new location,
but you can do that too at the following URL (slightly diff):

  http://disobey.com/noos/LibDB/dev/admin.cgi?tmpl=locations&edit=1

Go ahead and add one, and you'll be told your changes have been
saved, as well as given a chance to re-edit your changes or what
have you. You'll also notice that all these edits and additions
will apply to the "add_film" page above - once you're down fiddling
with locations, reload the "add_film" page, and you should see your
changes reflected in the "where is this item located" drop-down.

Still need to add a delete button too (though, that causes some
database integrity problems, so I may hold off on that for now).

-- 
Morbus Iff ( tomorrow never comes until it's too late )
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

Re: [libdb-develop] Don't Look At This Demo

[Bruce D'A. <da...@mu...>]

On Feb 20, 2004, at 12:31 AM, Morbus Iff wrote:

> Go ahead and add one, and you'll be told your changes have been
> saved, as well as given a chance to re-edit your changes or what
> have you. You'll also notice that all these edits and additions
> will apply to the "add_film" page above - once you're down fiddling
> with locations, reload the "add_film" page, and you should see your
> changes reflected in the "where is this item located" drop-down.

I just added a couple of examples that I could use: archival and online 
uri.

This raises a point: you're current UI works for videos on a shelf, but 
I don't think it does for my examples (where the location is more fine 
grained).  If I store an an online newspaper article record, I need to 
have the complete uri, along with a date accessed.

Bruce

Re: [libdb-develop] Don't Look At This Demo

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

 >This raises a point: you're current UI works for videos on a shelf, but
 >I don't think it does for my examples (where the location is more fine
 >grained).  If I store an an online newspaper article record, I need to
 >have the complete uri, along with a date accessed.

Yeah, the current focus of LibDB is physical materials. I haven't
given digital material much thought, but you could do the following
in the current system and it'd work well enough (in fact, I'm jotting
down a note to include "URI" as a default annotation):

  * define a location called "Online" (or some such). locations
    are solely relationships: besides describing a location type,
    you can't add *per-item* metadata to them. but...

  * define an annotation called "URI". annotations are defined
    as relationships too, but you can add as many strings per
    annotation type per item as you want. they have nothing to
    do with locations, so ultimately, you could leave the location
    of an item blank, and just use the "URI" annotation.

With the above, you could have:

  Location Type: Online
  Annotation Type: URI

  Title: Online Newspaper Record
  Location: [Location Type: Online; no value, relationship only.]
  Annotation: [Annotation Type: URI; Value: "http://www.demo.com/"]
  Annotation: [Annotation Type: URI; Value: "http://www2.demo.com/"]
  Annotation: [Annotation Type: URI; Value: "http://bak.offsite.com/"]

Would that work for you?

 >So what is a location? Say I want to store a bunch of records from an
 >archival collection. So: ABC Archive, Collection X, Box 23, Folder 324
 >How does this fit in the model?

 From an "FRBR model" standpoint, it really doesn't. FRBR mentions that
an item is located somewhere, but it doesn't set out to conceptualize
"location" as anything but a relationship/attribute.


-- 
Morbus Iff ( i put the demon back in codemonkey )
Culture: http://www.disobey.com/ and http://www.gamegrene.com/
Spidering Hacks: http://amazon.com/exec/obidos/ASIN/0596005776/disobeycom
icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus

Re: [libdb-develop] Don't Look At This Demo

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

 >Yeah, the current focus of LibDB is physical materials. I haven't
 >given digital material much thought, but you could do the following
 >in the current system and it'd work well enough (in fact, I'm jotting
 >down a note to include "URI" as a default annotation):
 >
 >  * define a location called "Online" (or some such). locations
 >    are solely relationships: besides describing a location type,
 >    you can't add *per-item* metadata to them. but...
 >
 >  * define an annotation called "URI". annotations are defined
 >    as relationships too, but you can add as many strings per
 >    annotation type per item as you want. they have nothing to
 >    do with locations, so ultimately, you could leave the location
 >    of an item blank, and just use the "URI" annotation.
 >
 >With the above, you could have:
 >
 >  Location Type: Online
 >  Annotation Type: URI
 >
 >  Title: Online Newspaper Record
 >  Location: [Location Type: Online; no value, relationship only.]
 >  Annotation: [Annotation Type: URI; Value: "http://www.demo.com/"]
 >  Annotation: [Annotation Type: URI; Value: "http://www2.demo.com/"]
 >  Annotation: [Annotation Type: URI; Value: "http://bak.offsite.com/"]

Replace "annotation" with "identifier". URIs are identifiers.


-- 
Morbus Iff ( i put the demon back in codemonkey )
Culture: http://www.disobey.com/ and http://www.gamegrene.com/
Spidering Hacks: http://amazon.com/exec/obidos/ASIN/0596005776/disobeycom
icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus

Re: [libdb-develop] Don't Look At This Demo

[Bruce D'A. <bd...@fa...>]

On Feb 20, 2004, at 9:51 AM, Morbus Iff wrote:

> Would that work for you?

If I understand what you are saying, it is analogous to how MODS deals 
with locations:

<location>
    <physicalLocation>whatever</physicalLocation>
</location>

<location>
    <url 
dateLastAccessed="2003-10-21">http://www.example.net/test.xml</url>
</location>

So if you were to represent your video shelf in XML, it might well be:

<location>
    <physicalLocation type="shelf">whatever</physicalLocation>
</location>

Is that right?  (Note, though: MODS doesn't actually have such an 
attribute, but it does have "authority" and "displayLabel", which could 
be used for this sort of thing)

> >So what is a location? Say I want to store a bunch of records from an
> >archival collection. So: ABC Archive, Collection X, Box 23, Folder 324
> >How does this fit in the model?
>
> From an "FRBR model" standpoint, it really doesn't. FRBR mentions that
> an item is located somewhere, but it doesn't set out to conceptualize
> "location" as anything but a relationship/attribute.

Which is a problem in the real world.  Clearly the FRBR is a 
meta-model; it solely defines broad structures.  But implementations 
need to sort out these details.  I'm not exactly sure how to deal with 
this, but I get the feeling there's an elegant way to do just that.

Gotta go...

Bruce

Re: [libdb-develop] Don't Look At This Demo

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

 >it is analogous to how MODS deals with locations:
 >
 ><location>
 >    <physicalLocation>whatever</physicalLocation>
 ></location>
 >
 ><location>
 >    <url dateLastAccessed="2003-10-21">http://www.example</url>
 ></location>
 >
 >Is that right?  (Note, though: MODS doesn't actually have such an
 >attribute, but it does have "authority" and "displayLabel", which could
 >be used for this sort of thing)

In essence, yes (though, I'm not sure how I'd represent dLA).
The MODS exporter of LibDB would have to be hardcoded to *know*
that a URI identifier belongs as a <url> <location> though. That's
not too worrisome though, because any sort of conversion format has
to know about to/from in a hardcoded sorta way.

 >> From an "FRBR model" standpoint, it really doesn't. FRBR mentions that
 >> an item is located somewhere, but it doesn't set out to conceptualize
 >> "location" as anything but a relationship/attribute.
 >
 >Which is a problem in the real world.  Clearly the FRBR is a
 >meta-model; it solely defines broad structures.  But implementations
 >need to sort out these details.  I'm not exactly sure how to deal with
 >this, but I get the feeling there's an elegant way to do just that.

Welp, what are your requirements for a "location"?

-- 
Morbus Iff ( i put the demon back in codemonkey )
Culture: http://www.disobey.com/ and http://www.gamegrene.com/
Spidering Hacks: http://amazon.com/exec/obidos/ASIN/0596005776/disobeycom
icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus

[libdb-develop] locations

[Bruce D'A. <bd...@fa...>]

On Feb 20, 2004, at 10:54 AM, Morbus Iff wrote:

> >> From an "FRBR model" standpoint, it really doesn't. FRBR mentions 
> that
> >> an item is located somewhere, but it doesn't set out to 
> conceptualize
> >> "location" as anything but a relationship/attribute.
> >
> >Which is a problem in the real world.  Clearly the FRBR is a
> >meta-model; it solely defines broad structures.  But implementations
> >need to sort out these details.  I'm not exactly sure how to deal with
> >this, but I get the feeling there's an elegant way to do just that.
>
> Welp, what are your requirements for a "location"?

At minimum, the ability to distinguish physical locations (.e.g 
archival holding locations) from electronic.  For electronic, citations 
require date accessed info.

Beyond that, I've noted this awkwardness on the MODS list.  In this 
example (only quasi-hypothetical):

	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??

Ugh, am rambling...

Bruce

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

Re: [libdb-develop] locations

[Bruce D'A. <bd...@fa...>]

On Feb 21, 2004, at 9:13 PM, Morbus Iff wrote:

> I'm inclined to say "an electronic resource has an /identifier/ like a 
> DOI or URI, and not a /location/".

This is a reasonable conclusion to come to.  Indeed the MODS developers 
came to the same conclusion initially as well.   But then I and a 
couple of other people pointed out that a uri is a location too; or at 
least it can be thought of in such a way.  A DOI is an identifier that 
can resolve to a location (a url), is how I'd tend to think of it.

Still, I agree this isn't anything critical now.  I'm just throwing 
these ideas out there for you to consider now; not necessarily to 
resolve them all at once...

Bruce

Re: [libdb-develop] locations

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

>This is a reasonable conclusion to come to.  Indeed the MODS developers
>came to the same conclusion initially as well.   But then I and a
>couple of other people pointed out that a uri is a location too; or at
>least it can be thought of in such a way.  A DOI is an identifier that
>can resolve to a location (a url), is how I'd tend to think of it.

Quite true, but they're identifiers first - they're "higher"
in the hierarchy of intent (DOI to URL, URI to URL). Just
because they *eventually* resolve to a location shouldn't classify
them as locations, anymore that an Amazon ASIN (which is ONLY
accessible via a URL/location) should be considered a location
*more* than an identifier.

Ultimately, with the Internet, *any* identifier shares the
same property as an electronic asset: an ISBN can be resolved
into a URL/location at ISBN.nu, UPCs are being stored in
upcdatabase.com, etc., etc.

-- 
Morbus Iff ( sleep breeds sanity )
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