Print

Print


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
>http://isni.org/isni/[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 http://www.isni.org/search
>
>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: http://nrs.harvard.edu/urn-3:hul.eresource:archives
>>> Twitter: @k8_bowers
>>>
>
>--
>Karen Coyle
>[log in to unmask] http://kcoyle.net
>m: +1-510-435-8234
>skype: kcoylenet/+1-510-984-3600