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.


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