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