It would be good to base this on the data structure proposed in the
recent DLF Electronic Resource Management Initiative -
http://www.diglib.org/pubs/dlfermi0408/dlfermi0408appc.htm . An
Organization (vendor etc.) provides an Electronic Product, which
comprises at least one Interface and at least one E-Resource.
E-Resources can contain other E-Resources. So, how about
vendorID:interfaceID:resourceID. That would let you group dbs that share
an interface, simplifying the management of linking algorithms etc. In
fact, for linking purposes you might not need more than
interfaceID:resourceID. You only care about the vendor for licensing
purposes. The cases John mentions where a given resource may or may not
give access to a bunch of sub-resources (depending on your license)
could be addressed by refering to interfaceID:resourceID/subresourceID
(xpath-style) when you're specifying one of those subresources, and
interfaceID:resourceID(subresource1, subresource2, ...) when you're
specifying the packages you actually have. This could all be nicely
structured in XML.

The DLF recommendations are likely to become the model for new ERMS
products; I know that Ex Libris has brought the data structures in SFX
into line with this (adding an interface layer) in preparation for their
Verde ERMS product. So it's likely to be the model we'll all be using as
we all get standards-based ERMS's in the next few years.

The ids used in the SFX knowledge base would fill the bill, but it would
be good to have a non-proprietary set. How about starting with the CUFTS
database? http://www.theresearcher.ca/product_component_cufts.html

Peter

Peter Binkley
Digital Initiatives Technology Librarian
Information Technology Services
4-30 Cameron Library
University of Alberta Libraries
Edmonton, Alberta
Canada T6G 2J8
Phone: (780) 492-3743
Fax: (780) 492-9243
e-mail: [log in to unmask]



> -----Original Message-----
> From: Code for Libraries [mailto:[log in to unmask]] On
> Behalf Of Ross Singer
> Sent: Friday, March 04, 2005 12:57 PM
> To: [log in to unmask]
> Subject: Re: [CODE4LIB] Authority Control for Databases
>
> John,
>
> This is a good question.  Of course, this isn't something
> that I figured could be solved in an afternoon (a Friday, at
> that!), but I think it warrants investigation.
>
> A way to address the situation you mention would be to add a
> 3rd field (maybe, I could be misunderstanding the problem) so:
>
> dbID:variantID:vendorID (or something)
>
> with variantID being a unique id to explain away the
> inconsistencies (:letters, :BCPapers, etc.)
>
> I don't really have a good answer in regards to "scope".  I
> think a definition of "database" would be in order.
>
> Maybe.
>
> -Ross.
>
> John Durno wrote:
>
> > I'd find something like this really useful for a couple of projects
> > I'm working on.
> >
> > I think the dbID:vendorID format could work quite well, as it
> > preserves both the fact that the content is the same and that it's
> > located in a different place. That's assuming that vendor
> here refers
> > to the host ... or does it refer to the publisher? Host would be
> > better I think, as there is generally only one publisher
> for a given
> > resource, but the host can often be any one of a number of service
> > providers. (eg. APA publishes PsycINFO ,which can be hosted
> by EBSCO,
> > ProQuest, OVID, etc.)
> >
> > There are complications arising from the fact that what
> constitutes a
> > "database" can be fairly fluid. eg. databases that consist
> of multiple
> > possible collections (thinking here of something like ProQuest's
> > Canadian Newsstand, which can be any or all of a number of regional
> > newspaper collections), or ebook databases like netLibrary.
> Not sure
> > how those kinds of content variations could be reflected in
> a standard
> > ID, or even if they should be.
> >
> > John
> >
> >
> > On 4-Mar-05, at 6:10 AM, Ross Singer wrote:
> >
> >> Thom,
> >>
> >> This is good news.  Whenever I think about this, I picture
> it looking
> >> something like a DOI:  like dbID:vendorID or something,
> but I don't
> >> know.  Do you have any details?
> >>
> >> Thanks,
> >> -Ross.
> >>
> >> Hickey,Thom wrote:
> >>
> >>> There's been some talk around here at OCLC about doing something
> >>> about this, especially to identify database-collections,
> which seem
> >>> to be entities people worry about too.
> >>>
> >>> --Th
> >>>
> >>>
> >>> -----Original Message-----
> >>> From: Code for Libraries
> [mailto:[log in to unmask]] On Behalf
> >>> Of Ross Singer
> >>> Sent: Friday, March 04, 2005 8:45 AM
> >>> To: [log in to unmask]
> >>> Subject: [CODE4LIB] Authority Control for Databases
> >>>
> >>> Is anybody aware of any type of standard identifier for
> databases?
> >>> Or any movement to create one?
> >>>
> >>> Matching on name seems very backwards.
> >>>
> >>> If there's not a group trying to create said authority, how could
> >>> something like that be started?  Would anybody else see
> value in this?
> >>>
> >>> Thanks,
> >>> -Ross.
> >>>
> >>>
> >>>
> >>
> >>
> > --
> > John Durno
> > Project Coordinator
> > BC Electronic Library Network
> > ~~~~~~~~~~~~~~~~~~~~
> > Phone: 604-268-7002
> > Fax: 604-291-3023
> > Email:   [log in to unmask]
> > Web: http://www.eln.bc.ca
> >
>