The basic question is how any authority serves to identify a particular
entity. A name string alone is not enough.  A declared relationship to a
title is better, especially if the title includes subject words and a
publication date relevant to the entity. More generalized information of
the type now included in RDA authorities provides additional support for
selection and identification.  Best (though never perfect) is when a
skilled person has reviewed an authority and confirmed that it
satisfactorily identifies a specific entity.

The BIBFRAME authority has a name string and a link to a bibliographic
description, so it implies a relation to a title; and the bib description
may include a role as part of its link to the BF authority, another bit of
identifying information. By itself, the BF authority would be inadequate
for identification purposes, but by extension, including information from
the bib descriptions it links to, it could suffice.  When a BF authority
also links out to an external authority (LCNAF, ISNI, whatever), any
information that authority can provide becomes part of this extend set of
identifying information.

All this depends on treating the BIBFRAME authority as more than just a
name string.  If the bib descriptions to which a BF authority is linked
internally are related to different entities rather than just one entity,
then the BF authority has no value for identification purposes.  It's hard
to see how any automated processing of a large database could reliably
generate useful BF authorities based on unqualified and unauthorized name
strings from bib descriptions (of which our large database has many).  If
the same name string appears on more than one bib description, either too
often different entities with undifferentiated name strings will be put on
a single BF authority, or too often multiple BF authorities for the same
entity will be created based on the name's appearance in multiple bib

If automated conversion of MARC records is part of the BIBFRAME plan, and
if automated generation of BF authorities is included in that conversion,
then we may want a way to indicate whether a BF authority is regarded as
identifying a specific entity uniquely, or as identifying a specific entity
but maybe not uniquely, or only as authorizing a common name and no
identity.  Either that, or we skip BF authorities in some cases and include
unauthorized name strings in BF bib descriptions.

One of the challenges going forward is formulating and operationalizing
brief presentations of this extended authority data which can do a better
job of supporting the identification function than our unique name strings
have done; but that's probably more for implementing systems to develop
than for BIBFRAME itself.

Responding Kelley's original questions: URI's have value as authorities
when they can return sufficient information to identify an entity.  That
wouldn't need to include a unique name string, but for many purposes would
need to include some kind of preferred name and be human-readable.

I like Kelley's suggestion that formal role identification be kept at a
more general level with the more unusual role labels retained as part of
the bib description, but not as new relators.  This reminds me a bit of the
MARC language codes, where more terms than codes are listed since some
languages are assigned only language group codes; except that the number of
unique relator terms is, on Kelley's evidence, infinitely expanding.


On Wed, Jan 21, 2015 at 10:37 AM, LAURA DAWSON <[log in to unmask]> wrote:

> As Product Manager for ISNI at ProQuest, and Treasurer of the ISNI Board
> of Directors, I applaud this suggestion. I may, however, be biased. ;)
> On 1/21/15, 11:35 AM, "Ed Jones" <[log in to unmask]> wrote:
> >One workaround for names (in many, if not most cases) would be (1) to use
> >ISNIs in those cases where a name authority record does not exist for an
> >author and (2) to make sure that newly created name authority records
> >routinely include ISNIs. Especially in the realm of scholarly
> >information, it is much more likely that an ISNI will exist for an author
> >(because he/she is recorded, for example, in Scholar Universe as the
> >author of an article). All ISNIs have persistent URIs in the form
> >[isni]. While ISNI records may include minimal
> >identifying information, they will typically include links to sources
> >(like Scholar Information) with sufficient information to identify the
> >individual.
> >
> >There are drawbacks, of course--more than on ISNI record may have been
> >created for a person, and ISNI identities don't always correspond to RDA
> >persons, etc.--but I think the advantages far outweigh the disadvantages
> >in terms of linking data.
> >
> >ISNIs can be searched at
> >
> >Ed Jones
> >National University (San Diego, Calif.)
> >
> >-----Original Message-----
> >From: Bibliographic Framework Transition Initiative Forum
> >[mailto:[log in to unmask]] On Behalf Of Karen Coyle
> >Sent: Wednesday, January 21, 2015 8:00 AM
> >To: [log in to unmask]
> >Subject: Re: [BIBFRAME] What will things and strings look like?
> >
> >That is "kind of" true although there are workarounds, some of which are
> >already used in BIBFRAME - create a blank node that can have a URI and/or
> >a label.
> >
> >You can also mix things and strings in OWL, using something called an
> >annotation property, but what you end up with is something that is not
> >very usable.
> >
> >This type of restriction isn't actually new, it just takes a different
> >form. For example, if you have a date field, in most programming
> >languages it needs to be either a structured string (yyyy-mm-dd) or a
> >free text field, but if you mix those you cannot take advantage of the
> >structured dates in applications. Things and strings are pretty much the
> >same - strings aren't "application friendly".
> >
> >I agree with Kelley and others that we will need a way to punt on nearly
> >every place in our data where a URI would be desirable. The perfect world
> >where a drop-down provides the "fill-in" precisely when you need it does
> >not exist. It would be great to hear from anyone developing BIBFRAME
> >input flows on how they are handling this.
> >
> >kc
> >
> >
> >On 1/20/15 10:07 PM, Shlomo Sanders wrote:
> >> I agree.
> >> But, as far as I understand, Either a value in a triple is a "string"
> >>or it is a URI, and  never the 2 shall mix.
> >>
> >> Thanks,
> >> Shlomo
> >>
> >> Sent from my iPad
> >>
> >>> On Jan 20, 2015, at 19:31, Bowers, Kate A. <[log in to unmask]>
> >>>wrote:
> >>>
> >>> One of the problems with making all relationships "URI" is that this
> >>>is hugely time-consuming. Keying "Ken Smith, producer; Joe Jones,
> >>>director; Emily Simms, presenter" is easy.  Finding a record for "Ken
> >>>Smith" if one doesn't already exist?  Impossible level of work.  We
> >>>need to be able to say things in strings because we cannot possibly
> >>>make all the metadata into data.  Only for "traced" headings would this
> >>>be possible, and we don't typically trace these all these pieces of
> >>>data.
> >>>
> >>> Kate
> >>>
> >>> Kate Bowers
> >>> Collections Services Archivist for Metadata, Systems, and Standards
> >>> Harvard University Archives [log in to unmask]
> >>> 617.496.2713
> >>> voice: (617) 384-7787
> >>> fax: (617) 495-8011
> >>> web:
> >>> Twitter: @k8_bowers
> >>>
> >
> >--
> >Karen Coyle
> >[log in to unmask]
> >m: +1-510-435-8234
> >skype: kcoylenet/+1-510-984-3600

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