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