 |
 |
No, that's the part that is likely to vary among systems. Using CUFTS would give us at least an openly available source of IDs, with broad coverage - son-of-JAKE. Those of us who are committed to proprietary systems like SFX would have to work out linkages from the CUFTS id for a given resource to the SFX id. If we do that, though, and we all use the DLF model, things get really interesting. Could I install your open-source DLF-compliant ERMS and easily populate it with data from my proprietary DLF-compliant linkresolver? Or write a simple API to let your ERMS talk to my linkresolver's knowledge-base on the fly to do its DLF-compliant admin work? Peter > -----Original Message----- > From: Code for Libraries [mailto:[log in to unmask]] On > Behalf Of Ross Singer > Sent: Friday, March 04, 2005 02:30 PM > To: [log in to unmask] > Subject: Re: [CODE4LIB] Authority Control for Databases > > 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 > >>> > >>> > >>> > > > > > > >