Actually, Karen, the ISNI database is chock-full of local identifiers so
that the data contributors can ingest their ISNI information/assignments
back into their databases. So itıs likely that the ISNI database will
become a massive hub of local identifiers for public identities. However,
itıs likely that some of the for-profit data contributors (such as
ProQuest and Bowker) will not really want those local identifiers
distributed into the overall supply chain, so the problem becomes one of
access.
On 1/20/15, 1:32 PM, "Karen Coyle" <[log in to unmask]> wrote:
>On 1/20/15 8:59 AM, Svensson, Lars wrote:
>> I guess this is a general case: What do I do when I want link to an
>>authority file and the entity I want to link to isn't there (yet)?
>This comes up not only for name authorities but for anything for which
>there is an authoritative list. For names you could have your system
>mint a local ID just to get the record done -- and that is what makes
>sense in terms of the data flow. I'm not sure that the same solution
>makes sense for the controlled lists like genres, roles, etc.
>
>Eventually one would want to do cleanup on those local URIs, matching
>them where possible to universal identifiers. This is one of those areas
>where we need to think through the bigger picture workflow. There are
>libraries today that if they don't find a record in OCLC for their copy
>cataloging needs they actually set the book aside and come back in a
>week or so to see if a record has shown up. I don't think a workflow
>that sets aside an item for every missing URI is going to be viable, but
>having a load of local URIs that never get upgraded to community URIs
>isn't going to be a solution either.
>
>I believe that BIBFRAME's lightweight abstract layer is an attempt to
>respond to this, although the next step -- matching up local URIs to
>community URIs -- hasn't been addressed, AFAIK.
>
>Kelley has helpfully brought up questions and situations that occur
>during cataloging. It is very important that workflow issues be
>addressed, even if they do not alter the content of BIBFRAME data.
>
>kc
>
>--
>Karen Coyle
>[log in to unmask] http://kcoyle.net
>m: +1-510-435-8234
>skype: kcoylenet/+1-510-984-3600
|
