Tuesday, May 14, 2013

BIBFRAME Authorities

There is a discussion taking place on the BIBFRAME listserv about the draft proposal for BIBFRAME Authorities. I've made some comments, but this is a topic that requires diagrams, and therefore doesn't work well in email. This blog post is an illustrated comment on the BIBFRAME Authorities proposal.

The way I read the proposal, this diagram represents the current thinking on BIBFRAME Authorities:

Here is an example of a BIBFRAME authority representation from the document:

<!--  BIBFRAME Authority -->
<Person id="http://bibframe/auth/person/franklin">
      <label>Franklin, Benjamin, 1706-1790</label>
      <hasIDLink resource="http://id.loc.gov/authorities/names/n79043402" />
      <hasVIAFLink resource="http://viaf.org/viaf/56609913" />
      <hasDNBLink resource="http://d-nb.info/gnd/118534912" />
</Person>
 
It is unclear to me what role or functionality the VIAF and DNB links are expected to have, so that is a question that I have. I don't know what "hasIDLink" means - whether that is specific to LCNA or means: "this is the authority file." If it does not mean that, then this does not link the BIBFRAME name display form specifically to the actual authority file that defined it. If it does mean that, then the three authority files are not treated consistently.

In addition, it does not appear that alternate name forms are including in the BIBFRAME Authority, so they are not available for indexing. That could just be something missing from the examples, however.

It would make more sense to me that if a BIBFRAME authority is needed in the BIBFRAME structure, to make a few changes. First, the alternate name forms would be included in the BIBFRAME authority, primarily for indexing. The preferred form of the name is obviously there for the purposes of display and indexing. The alternate forms are not displayed, but should be used in retrieval.

Another possible change is to make a direct link from the BIBFRAME authority to the library authority entry, in this case LCNA. Without this, it isn't clear how the two will be kept in sync as the LCNA file is updated. Links to other library authority files would be from the authority of record, which is what they are "nearly equivalent" to:
Note that this still links the annotations to the BIBFRAME authority. Other libraries using the LCNA data would not necessarily have access to annotations linked directly to the BIBFRAME authority, but that depends on how those authorities are shared. The advantage of this is that it shelters the "true authority" from possibly inappropriate stuff that might be associated with the BIBFRAME authority.

<!--  BIBFRAME Authority -->
<Person id="http://bibframe/auth/person/franklin">
      <label>Franklin, Benjamin, 1706-1790</label>
      <altLabel>Franklin, V. (Venīamin), 1706-1790</altLabel>
       <authority resource="http://id.loc.gov/authorities/names/n79043402" />
</Person>
 
<!-- LC Name Authority -->
 
  <madsrdf:PersonalName rdf:about="http://id.loc.gov/authorities/names/n79043402">

      <madsrdf:authoritativeLabel xml:lang="en">Franklin, Benjamin, 1706-1790
        </madsrdf:authoritativeLabel>
      <madsrdf:variantLabel xml:lang="en">Franklin, V. (Venīamin), 1706-1790
        </madsrdf:variantLabel> 
      <hasVIAFLink resource="http://viaf.org/viaf/56609913" />
      <hasDNBLink resource="http://d-nb.info/gnd/118534912" /> 
  </madsrdf:PersonalName>

The last option that I can propose is that of simply using the library authority. I believe that the argument against this is that such data may not always be available for record displays but as far as I know nothing prevents caching of high-use metadata statements ("triples" because it's all just triples after all), and refreshing these periodically to make sure one has the latest. In fact, it is probable that the linked data space will take a lesson from the Domain Name System, where a system of mirrors and backups distributes the DNS world-wide, syncs changes, and provides almost 100% availability. In that case, there would be no reason not to use ones' stated authority, with similarly coded local data existing where the authority data does not exist for the occasional local need.
<!--  BIBFRAME Authority -->
<Person id="http://id.loc.gov/authorities/names/n79043402"></Person>
 
<!-- LC Name Authority -->
 
  <madsrdf:PersonalName rdf:about="http://id.loc.gov/authorities/names/n79043402">
      <madsrdf:authoritativeLabel xml:lang="en">Franklin, Benjamin, 1706-1790
        </madsrdf:authoritativeLabel>
      <madsrdf:variantLabel xml:lang="en">Franklin, V. (Venīamin), 1706-1790
        </madsrdf:variantLabel> 
      <hasVIAFLink resource="http://viaf.org/viaf/56609913" />
      <hasDNBLink resource="http://d-nb.info/gnd/118534912" /> 
  </madsrdf:PersonalName>

To be sure, I am making some assumptions that should be explicit.
  1. It's all triples. It's easy to forget this when looking at graphs.
  2. Availability is a technical issue for which there is an answer (or more than one answer)
  3. The main action in a linked data space is a query. This is not only for traditional discovery, but also for forming displays. To display a person's name will be a query for a "label" linked to a URI. It doesn't matter whether the URI is a BIBFRAME authority URI, an LCNA URI, or a DNB URI -- each of those is a triple in linked data space.

1 comment:

Unknown said...

I think variant 3 (using the entity's URL directly) is best. The variants with indirection go against LD linking principles, and have typing problems. An author is a person (or agent, or institution), not a BibFrame Authority. The place of publication is a place, not a BibFrame Authority.

There is no problem to "cache" pref/alt names in the local repository by recording them as triples against the direct URL.
There is also no problem to list several authority URLs by interlinking them with owl:sameAs, skos:exactMatch, lingvo:strictlySameAs or whatever is appropriate. Or if BibFrame doesn't want any of the "sameness semantics", it can just use a custom property like bf:sameAuthorityAs (but better be symmetric).