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