Thanks for responding to with the update from the PCC URIs Task Group work, timely.
I just want to point out a bit of nuance found in the discussion paper:
“Note on all options: Authority URIs gathered in the 024 should be an exact match of the base MARC Authority, and RWO URIs are recommended to be the primary focus of the base MARC Authority. Such scoping of URIs in the 024 negates any need to introduce $4 in the MARC Authority 024. It allows $0 URIs to reliably be considered a skos:exactMatch to the base Authority, and 024 $1 URIs to reliably be considered the foaf:focus of the base Authority.”
So, depending on whether there is a $0 or $1 we might use different mapping properties. For example, we wouldn’t want to use skos:exactMatch on a $1 RWO URI because the range of skos:exactMatch is a skos:Concept.
It’s also worth recognizing also that each data provider might have different levels of confidence in the source data, and this might color how strong they want assert mappings when they convert to linked data. The safest approach would be to initially use more loosely defined properties and maybe ratchet up the semantics when we have more experience and confidence in the data. While we might aspire to skos:exactMatch and foaf:focus… skos:closeMatch for Authorities and rdfs:seeAlso for RWO’s might be a nice first step in conversion, until we can test how well we capture these identifiers/URIs.
Cornell University Library
The PCC URI Task group is currently discussing/collaborating with NACO representatives on best practices for the AUTH 024 pending submission, approval, and implementation of a MAC proposal resulting from the DP referenced below. We expect to submit that AUTH 024 proposal at ALA Midwinter.
At ALA Annual, MAC agreed to allow the PCC URI TG to present an AUTH 024 proposal using option 2 from the DP, where machine dereferenceable URIs (for RDF use) are only added to $0 or $1, in line with the use and definitions of those subfields for BIB records. URNs would go in $a. There is no subfield provision for recording URLs in AUTH 024.
Note that the DP specifies that URIs referenced in the AUTH 024 should be skos:exactMatch to the Subject of the AUTH record.
Machine dereferenceable URIs in $a are pretty useless for RDF conversion as the kind of URI ($0/authority or $1/Real World Object) cannot easily be discerned and MAC will not require that URIs in $a be migrated to $0 and $1 if the upcoming AUTH 024 proposal is accepted.
In addition, NACO and PCC need to determine whether or not the URI sources allowed in 024 should be proscribed and managed to maintain the quality of NACO data.
Nancy J. Fallgren
Senior Metadata Librarian
Cataloging and Metadata Management Section
Technical Services Division, Library Operations
National Library of Medicine
Thanks for the prompt response!
I’m not part of the URIs in MARC records task force, so I can’t speak on the issue of having both identifiers and URIs in the 024 - although their FAQs state that only the URI should be inputted. The decisions on the MARC discussion paper 2018-DP08 should shed some light on the issue.
The MARC to MADSRDF for NAF records does not address 024 at all yet. The VIAF link is generated dynamically to resolve correctly based on the LCCN. This was done back in the old days when VIAF numbers were not necessarily in the marc data.
Now that there are more 024s, I think we need to start saying what they mean.
Has it been agreed that 024s that are uris be hasExactExternalAuthority uris, with RDF on the other end?
As the MARC documentation currently exists, http://www.loc.gov/marc/authority/ad024.html I’d be inclined to express them as madsdf:hasIdentifier or madsrdf:see, or hasCloseExternalAuthority , before I’d say hasExactExternalAuthority.
Is it expected that 024 is always external?
For your Keiko example, http://id.loc.gov/authorities/names/no2013017876.marcxml.xml, the NNDB “people” link only resolves as html as far as I can tell. It may be an authority, but it’s not available as RDF.
curl -L -H "Accept:application/rdf+xml" http://www.nndb.com/people/743/000026665/
I think once the dust settles on what 024 uris mean and how close the relationships are between some of these authorities, we will update the transformation. We might just go ahead and start adding them at least as identifiers. (I don’t understand why some are listed as both numbers and URIs; that introduces unnecessary complications.)
Hope you as PCC can add some clarity so we get the relationships right.
Network Development & MARC Standards Office
LA308, Mail Stop 4402
Library of Congress
Washington DC 20540
Dear collective wisdom,
I had a couple of questions about sameAs relationships in authority records as expressed in id.loc.gov that hopefully some of you can clarify for me:
- How are the mads:hasExactExternalAuthority relationships created?
- Why are the links generated not VIAF URIs?
- Why are identifiers added in 024s in the NARs not appearing as mads:hasExactExternalAuthority?
- Are there any plans to make those connections visible in the front end?
(An example record with 024s that are not made apparent in id.loc and with a funky VIAF url (not URI) is no2013017876)