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