 |
 |
I think this is a fantastic idea. The only part I haven't "gotten", is the "resourceID" consistent? Is there some group that decides on this? I like the idea of CUFTs as a starting point (and, on review, it's nice to see Mark doesn't mind this :) Any III people out there that can tell us how this works in their ERM? Thanks for pointing this out, Peter. -Ross. 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 >>> >>> >>> > > >