 |
 |
Hi Peter, Right now, CUFTS only contains collections of ejournals but there are plans to have it include other resources as well. A registry of IDs could be added, in the spirit of the other public tools listed at http://cufts.lib.sfu.ca/tools.shtml . I agree about using the DLF ERM framework, since it is an open spec _and_ library system vendors (like Innovative) are already adopting it. Mark Mark Jordan Acting Coordinator of Library Systems W.A.C. Bennett Library, Simon Fraser University Burnaby, British Columbia, V5A 1S6, Canada Phone (604) 291 5753 / Fax (604) 291 3023 [log in to unmask] / http://www.sfu.ca/~mjordan/ On Fri, Mar 04, 2005 at 02:00:16PM -0700, Binkley, Peter wrote: > 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 > > > > > --