 |
 |
A cautionary note. Linked data works best when the entities identified by URIs are unambiguous. That's not always the case with VIAF and ISNI. They aggregate data from other ID registries algorithmically and with limited review. High-performing algorithms still make mistakes, as do the more manually built descriptions they depend on. I did a search in VIAF on "morgan, eric" (which retrieves names matching and associated with "eric morgan") and found matched records ISNI 0000000116490460 / VIAF 56843669, both of which conflate the physicist Patricia Lewis, born 1957 per the LCNAF record where she's "Lewis, P. M.", and lecturer on management Patricia Lewis, born 1963 per the LCNAF record where she's "Lewis, Patricia, 1963-", and a "Lewis, Patricia, 1954-" who appears to be a French Canadian author writing in French on emotions from a self-help perspective, who has been confused with the management lecturer who also writes on emotions from a management perspective. I also noted ISNI 0000000384457106 / VIAF 275988911, both associated with the management lecturer's LCNAF authority, so she effectively has two ISNI and VIAF IDs. And the first title cited in the LCNAF authority for physicist "Lewis, P. M." is a document on the effects of shift work produced in Washington State for the US Nuclear Regulatory Commission in 1985. That doesn't match with the physicist Lewis's biography in Wikipedia. A bit more poking around in OCLC suggests this work belongs instead to Paul Michael Lewis, who has contemporaneous works for the NRC on work schedules in the Pacific Northwest. He's not properly established at all in LCNAF; nor is the French Canadian author. This kind of sifting of data is what takes time in authority work, and what--when it's done well--makes authority data valuable for the semantic web. The point of the above is NOT that algorithmic aggregation is a bad idea--just that it leaves a lot of necessary work still to do. Cases like the above are too easy to find at present in VIAF and ISNI. ISNI has been very responsive for me when I've reported problems (and I will work to resolve the problems noted above), but much remains to be done. Rather than leaping ahead to more algorithmic matching of VIAF and ISNI IDs to other identity records, I'd like to see developers work on programs which could mine ISNI and VIAF to detect discrepancies in the aggregated ID sources for further review. That could reduce the proliferation of errors already in the data records and make all of these data resources ultimately more valuable for semantic web use. Stephen On Fri, Apr 15, 2016 at 10:57 AM, Kyle Banerjee <[log in to unmask]> wrote: > On Fri, Apr 15, 2016 at 2:16 AM, Eric Lease Morgan <[log in to unmask]> wrote: > > > ... > > My questions are: > > > > * What remote authority databases are available programmatically? I > > already know of one from the Library of Congress, VIAF, and probably > > WorldCat Identities. Does ISNI support some sort of API, and if so, where > > is some documentation? > > > > Depends on what you have in mind. For databases similar to your example, I > believe ORCID has an API. GNIS, ULAN, CONA, and TGN might be interesting to > you, but there are tons more, particularly if you add subject authorities > (e.g. AAT, MeSH). The Getty stuff is all available as LoD. > > * I believe the Library Of Congress, VIAF, and probably WorldCat > > Identities all support linked data. Does ISNI, and if so, then how is it > > implemented and can you point me to documentation? > > > > * When it comes to updating the local (MARC) authority records, how do > > you suggest the updates happen? More specifically, what types of values > do > > you suggest I insert into what specific (MARC) fields/subfields? Some > > people advocate $0 of 1xx, 6xx, and 7xx fields. Other people suggest 024 > > subfields 2 and a. Inquiring minds would like to know. > > > > Implementation would be specific to your system and those you wish to > interact with. The MARC record is used to represent/transmit data, but it > doesn't actually exist in the sense that systems use it internally as is. > > Having said that, I think the logical place to put control numbers from > different schema is in 024 because that field allows you to differentiate > the source so it doesn't matter if control numbers overlap > > kyle > -- Stephen Hearn, Metadata Strategist Data Management & Access, University Libraries University of Minnesota 160 Wilson Library 309 19th Avenue South Minneapolis, MN 55455 Ph: 612-625-2328 Fx: 612-625-3428 ORCID: 0000-0002-3590-1242