Print

Print


Mostly reiterating points that Richard has already made:

Option 3 has the advantage of being fairly easy to implement. It uses
functionality already built into most relevant systems; it relies on data
already available in existing authorities; and it will differentiate
currently undifferentiated names in all the cases we know of.  In the
majority of cases, the title referenced in a 670 will be useful in a $c in
identifying a person even before a full authority is examined, and more
useful for that task than such currently accepted qualifiers as dates and
fuller form.

A good solution will need to differentiate names in order to collocate the
works of different persons in separate sets. A solution which will
differentiate identities but won't enable distinct collocations of works
under distinct access points for each identity is unsatisfactory. A
solution which depends on reconfiguring indexing programs is likely to face
a significant delay in implementation, though as Philip says, reconfiguring
indexing programs to rely more in ID matches than text string matches is a
goal we all share.

OCLC currently embeds its own Authority Record Number (ARN) in an
authorized bib access point when the Control Headings function is used.
 One could ask OCLC simply to supplement these ARNs with LCCNs. OCLC's
indexing however does not differentiate entries based on this bit of data.
Hence, a list of works under "Smith, John" will likely contain controlled
entries for "Smith, John," uncontrolled entries for the same "Smith, John,"
and uncontrolled entries for other persons named John Smith. The control
function is not able to pull together works under the controlled "Smith,
John" for catalogers or users. The names are effectively still
undifferentiated.

The work needed to correctly match currently undifferentiated and
uncontrolled bib entries with newly differentiated authorized access points
will be onerous in any scenario. But at least under Option 3 it will
differentiate the collocations of bib records for users. Under Option 4
it's not clear that the work of differentiating the authorities and
associating them with bib entries would have any benefit for users without
significant reprogramming.

Stephen



On Tue, Jun 11, 2013 at 4:46 AM, Moore, Richard <[log in to unmask]> wrote:

> Adam****
>
> I recognise that Option 3 isn�t perfect, but the one thing Option 4
> doesn�t actually do is create differentiated authorised access points, so
> it falls at the first hurdle. �Undifferentiated� is a property of
> authorized access points, not of authority records. ****
>
> My take on your observations:****
>
> The title information in an undifferentiated NAR is the first thing a
> cataloguer looks at when deciding whether a person is the one they want,
> It�s the most significant, and often the only information available. Using
> this information as a qualifier (Option 3) makes it visible in a browse
> list and, if anything, speeds work up, as the access point required will
> often stand out. On the other hand, to replace the undifferentiated NAR
> with a list of identical unqualifed names (Option 4) means that every NAR
> must be examined at random until the correct one is found.****
>
> A cataloguer can only specify a link to the appropriate NAR in new
> cataloguing. The rest is BFM, if we want our bib records to link to
> authorities. Whatever may become possible in Connexion, not everyone uses
> it (we don�t).****
>
> Existing records will only function in OPACs as they currently do, if BFM
> is done to link them to their authorities. All BFM is onerous. Under either
> option, the bib headings remain undifferentiated until someone aligns them
> to their authority. The difference is that under Option 3 the BFM provides
> a benefit to the patron, in terms of user tasks, and under Option 4 it
> doesn�t. Moreso, Option 4 would be horribly confusing both to catalolguers
> and to users, as we�d have undifferentiated names for multiple people in
> our catalogue, that matched (but did not link to) multiple authorized
> access points in NARs, with the same form. This assumes that you have
> linked authorities in your OPAC in the first place, which we, as Primo
> users, do not. If all your OPAC provides is a list of name headings in bib
> records, then Option 4 is even less helpful.****
>
> We made a strong distinction in our report between the post-MARC future
> (identifiers, post-co-ordination and linked data) and methods for creating
> undifferentiated access points in the medium term. In the medium term,
> Option 4 does not differentiate access points (in RDA, �Identifier for
> the Person� is not part of the access point). In the longer term, Option 4
> is not necessary, as the LCCN is already present in the NAR, along (soon)
> with other identifiers such as ISNI.****
>
> ** **
>
> Regards****
>
> Richard****
>
> _________________________****
>
> Richard Moore ****
>
> Authority Control Team Manager ****
>
> The British Library****
>
>                                                           ****
>
> Tel.: +44 (0)1937 546806                       ****
>
> E-mail: [log in to unmask]                             ****
>
>  ****
>
> *From:* Program for Cooperative Cataloging [mailto:
> [log in to unmask]] *On Behalf Of *Adam Schiff
> *Sent:* 11 June 2013 09:34
> *To:* [log in to unmask]
>
> *Subject:* Re: [PCCLIST] Report of the Task Group on the Creation and
> Function of Name Authorities in a non-MARC Environment****
>
> ** **
>
> Richard et al.,****
>
>  ****
>
> There are seveal reasons I dislike option 3.  The qualifiers proposed to
> be used are quite unwieldy and I strongly dislike the examples in the
> report that use ellipses.  Those look very strange to me when included as a
> qualifier:****
>
>  ****
>
> 100 1 $a Young, Frank A. $c (Author of Duluth�s ship canal and aerial
> bridge �)****
>
>  ****
>
> The option, also seems to be predicated on such persons only being
> associated with one work.  Maybe this is the case for the majority of the
> undifferentiated names in the LC/NACO NAF.  But for persons who are
> associated with multiple works, particularly if the works are not similar
> in nature, I think using a qualifier with a single title could be
> misleading to users and catalogers, who might not easily be able to
> identify that the entity in question is the same one they are seeking.
> Seeing a qualifier (Author of Title 1) in an access point might cause users
> to skip that access point if they are looking for the author of a different
> work who really is the same person responsible.  One way to solve this
> might be to make variant access points with qualifiers that include the
> titles of other known works by that person, but I think that still could be
> confusing in catalogs.  ****
>
>  ****
>
> 100 1 $a Smith, John $c (Author of Title A)****
>
> 400 1 $a Smith, John $c (Author of Title B)****
>
> 400 1 $a Smith, John $c (Producer of Title C)****
>
> 400 1 $a Smith, John $c (Illustrator of Title D)****
>
>  ****
>
> This solution would probably help catalogers pick the correct entity more
> easily, but inevitably catalogers will STILL need to examine multiple
> authority records to determine if the person they are looking for already
> has an authorized access point in the NAF or not.  So I don�t see the
> argument that you mention of catalogers needing to examine multiple
> authority records if option 4 is selected compelling.  If you have a
> different work from the one in the qualifier, you will still need to
> examine multiple authority records to see if you find a match.****
>
>  ****
>
> The way I envision option 4, OCLC and PCC would authorize the inclusion of
> subfield $0 in access points in bibliographical records.  This would allow
> the cataloger to specify a link to the appropriate NAR.  The LCCN in $0
> would not be part of the access point and would not (should not?) be
> displayed in catalogs.  Separate NARs for persons with the same access
> point would be created instead of an undifferentiated NAR.  Since the
> cataloger already has to examine multiple records to pick the correct NAR,
> it�s little additional work to add the $0 into a bibliographic access
> point.  Even without it, OCLC would be able to control the access point if
> the cataloger uses the control software in Connexion and chooses the
> correct record.  But by adding the $0 into the 100/700/800 field, the
> system would automatically know which NAR to link to, and the controlling
> feature in OCLC should become simpler.  If the access point in the NAR is
> later able to be actually differentiated by additional elements like dates
> or occupation, the access points in bib records could automatically be
> flipped to the differentiated for.  Authority vendors and ILS should also
> fairly easily be able to make flips of bib access points when the NAR is
> differentiated since the $0 provides a link.****
>
>  ****
>
> BFM of bibliographic records, no matter what option is chosen, is going to
> be a huge and onerous task, and I was very disappointed that the task
> force�s report does not really address this issue of how we would achieve
> clean up of our data.  At least with the option 4, the names don�t change,
> and can be left as is in our records.  In other words, the impact on
> bibliographic file maintenance is minimal and existing records will
> function as they currently do in our OPACs.  Perhaps authority vendors
> might have the ability to process our bibliographic records and automate
> the addition of the $0s, but few of us will have the staff and resources to
> retrospectively deal with matching records to the newly differentiated NARs
> proposed through option 3.  For this reason above all, I think option 4 is
> a better way to go for now.****
>
>  ****
>
> Adam Schiff****
>
> Principal Cataloger****
>
> University of Washington Libraries****
>
>  ****
>
> *From:* Moore, Richard <[log in to unmask]> ****
>
> *Sent:* Tuesday, June 11, 2013 12:10 AM****
>
> *To:* [log in to unmask] ****
>
> *Subject:* Re: Report of the Task Group on the Creation and Function of
> Name Authorities in a non-MARC Environment****
>
>  ****
>
> Philip****
>
>  ****
>
> Thanks for your reply. I agree that all options should be carefully
> considered. Please would PoCo to consider the following points? I can�t
> speak for the whole Group, and people argued the case for all Options.
> However, these are among the reasons we plumped for Option 3 as the most
> practical way to abolish undifferentiated NARs and create unique access
> points in the medium term.****
>
> Adding an LCCN to a name, whether displayed or not, does not differentiate
> it. Although to do this would create unique NARs, it would not create
> undifferentiated names. To the user they all look the same.****
>
> The cataloguer would have to examine multiple authority records with the
> same authorised access point, rather than scanning one undifferentiated
> record. Unless we add something meaningful to the new access points, we are
> better off with undifferentiated NARs.****
>
> We have many uncontrolled, unqualified access points in our database, and
> we devote considerable resources to aligning them to LC/NAF. Trying to
> match multiple unqualified identities on our database with multiple
> unqualified entities on LC/NAF is a recipe for confusion. Again, it�s
> easier with undifferentiated NARs.****
>
> Unless the many and varied providers of the bibliographic records that we
> rely on for our workflows are able to include the correct LCCN, we will
> receive a lot more records needing authority control work, than if
> differentiated, qualifed headings are available for them to use.****
>
> We would have considerable system issues in making this work at all, let
> alone work correctly.****
>
> Option 3 was the only option that actually differentiated the names. We
> agreed that identifiers are the future, but identifiers are designed to be
> manipulated by machines, whereas authorised access points need to be read
> by people. For as long as we need these strings, they need to be unique and
> intelligible. ****
>
> I take your point that the work-related qualifer might not relate to the
> title in hand, but I�m not sure this is a stronger objection than to the
> use of an RDA qualifer for Profession or Occupation. It might be more
> informative to the user than an occupation, or a date of birth. Having said
> that, I think cataloguers should be allowed to replace these qualifers if
> they came up with something more durable.****
>
> Once we were able to implement Option 1, wouldn�t we be stripping out **
> all** qualifers and moving to post-coordination of the data in the NAR?
> I�m not the sure the work-related qualifer is special in that regard.****
>
> Option 3 has the advantage of providing an intelligible qualifier that
> will (with the 2012 changes due next month) be allowable under RDA as an
> �Other designation�. It gives scannable information to the patron, and to a
> cataloger doing authority work. It�s not ideal, but is better than the
> alternatives. For example, �Author� would already be legal in RDA as a
> person�s Profession or Occupation � although it�s hard to think of a less
> useful qualifier in a NACO context. There is nothing to stop cataloguers
> creating unique NARs with this qualifier. It seems to me that �Author of
> Fishing in Maine� is much  more useful.****
>
> The other main advantage of Option 3 is that it is easily programmable and
> can be done quickly and easily, with no need for any changes to systems,
> policies or rules, whatever.****
>
> The same amount of BFM will be required however the names are
> differentiated. It will be required if we add LCCNs instead of meaningful
> qualifiers, as the LCCNs will also need to be in the bib records if they
> are to link to the correct authorities. However, we would then have done
> all the BFM, without actually differentiating the access points.****
>
>  ****
>
> Regards****
>
> Richard****
>
>  ****
>
> _________________________****
>
> Richard Moore ****
>
> Authority Control Team Manager ****
>
> The British Library****
>
>                                                           ****
>
> Tel.: +44 (0)1937 546806                       ****
>
> E-mail: [log in to unmask]                             ****
>
>  ****
>
> ** **
>
>  ****
>
> *From:* Philip Schreur [mailto:[log in to unmask]<[log in to unmask]>]
>
> *Sent:* 10 June 2013 17:02
> *To:* Program for Cooperative Cataloging
> *Cc:* Moore, Richard
> *Subject:* Re: [PCCLIST] Report of the Task Group on the Creation and
> Function of Name Authorities in a non-MARC Environment****
>
>  ****
>
> Richard,
>
> Thanks for your note.  Any sort of decision is far from over and we hope
> to get input from our PCC members over the next month on all the issues in
> the report.  We (PoCo) were extremely pleased with the report and agree
> 100% that your Option 1 is our future and that we should move towards it as
> quickly as possible.  I believe the only area that provoked strong
> discussion was the recommendation on undifferentiated names.  It became
> clear from conversations within PoCo and also at OpCo that the proposed
> qualifiers in Option 3, while making the text strings unique, were not
> necessarily helpful to our patrons (for instance, if the work they were
> seeking had nothing to do with the work that was used to modify the
> author's name heading).  It was also felt that once we were in a position
> to implement Option 1, we would want to go back and strip out all these
> work related qualifiers.
>
> The forth option, we believe, would be least disturbing to patrons.  The
> LCCNs could be suppressed from display in discovery systems.  It is true
> that there could be identical headings for different entities in the
> catalog but these exist already as many headings are uncontrolled (order
> records, etc.).  These headings would also be a tabula rasa on which local
> systems could experiment with ad hoc qualifications for directed
> discovery.
>
> I agree that perhaps "unsafe" was not the best choice of terms.   We did
> feel, though,  that this additional option had strong merits and should be
> considered as well.  Authorities, from undifferentiated names to BIBFRAME's
> "light abstraction layer," will certainly be the most rapidly evolving part
> of our program.  I can't think of a more exciting time in which to be
> working.
>
> All the best.
>
> Philip
>
> On 6/9/2013 11:39 PM, Moore, Richard wrote: ****
>
> Philip****
>
> The Task Group discussed the option of using the LCCN to create unique
> access points in some detail. I think it would be unhelpful to the user,
> either to see apparently undifferentiated names if the LCCN were not
> displayed, or names differenatiated by something meaningless to them. This
> is why we recommended the use of intelligible text derived from 670 in the
> undifferentiated record. I�m not sure why this would be considered �unsafe�
> to do automatically, especially when the qualifiers suggested will be
> admissible under the July 2013 RDA update as �Other designations�, so
> people will be able to do this manually in any case. Perhaps we can revisit
> at a later date.****
>
>  ****
>
> Regards****
>
> Richard****
>
> _________________________****
>
> Richard Moore ****
>
> Authority Control Team Manager ****
>
> The British Library****
>
>                                                           ****
>
> Tel.: +44 (0)1937 546806                       ****
>
> E-mail: [log in to unmask]                             ****
>
>  ****
>
>          ****
>
>  ****
>
> *From:* Program for Cooperative Cataloging [
> mailto:[log in to unmask] <[log in to unmask]>] *On Behalf Of
> *Philip Schreur
> *Sent:* 06 June 2013 21:20
> *To:* [log in to unmask]
> *Subject:* [PCCLIST] Report of the Task Group on the Creation and
> Function of Name Authorities in a non-MARC Environment****
>
>  ****
>
> Everyone,****
>
> I'm extremely pleased to release the Report of the PCC Task Group on the
> Creation and Function of Name Authorities in a Non-MARC Environment to you
> for comment.  This Task Group, chaired by Stephen Hearn, was asked to think
> broadly and practically about identities in both an RDA and a linked data
> environment.  Key to the report would be the identification of changes
> needed to our current authority record system to support this new
> environment and proposed solutions to moving forward.  The report is
> divided into two parts, the first deals with alternatives to
> undifferentiated personal name authorities and the second to name
> authorities in a non-MARC environment.****
>
>  ****
>
> Earlier this month, both OpCo and PoCo had an initial discussion of the
> report.  As you read through the three options presented in Part 1, we
> would like you to consider a fourth option as well.  Our discussions led us
> to support investigating the use of the subfield |0 (subfield zero, defined
> in MARC21 as �Authority record control number�) in the authority file to be
> able to use the LCCN when no other text element is available to
> differentiate the authorized access point.  This differs from option 2 in
> that, while it would be included in the 1XX of the authority record, the
> LCCN would not be a parenthetical qualifier to the formal authorized access
> point, but rather a subfield used to distinguish identities that share the
> same text string.  Because the LCCN would not be an integral part of the
> authorized access point itself, display within the local system would be
> optional. In pursuing this option, a number of tangential issues would need
> to be investigated such as the NACO normalization rules, the proposed use
> of the |0 in authority records through the MARC Advisory Committee, impacts
> on authority vendors, and impacts on the ILS.  In addition, OpCo and PoCo
> discussed various ways to break up undifferentiated name clusters and
> associated bibliographic records with the correct name form.  There did not
> seem to be an automated way to do this safely and the work that would be
> required to do so manually is not feasible in the current environment. Any
> name, of course, can be extracted from these clusters at any point on an as
> needed basis.****
>
>  ****
>
> Part 2 of the report is the most far reaching.  We are currently
> considering how best to involve you in this discussion and hope to have an
> announcement to make at the PCC Participants meeting this summer in
> Chicago.  Thanks again to the members of this Task Group!  They had a very
> daunting charge and the report will help us move forward in uncharted
> waters.  Please share your comments with us by July 12th through the link
> provided below.****
>
>
>
> ****
>
> Report on Authorities in a non-MARC Environment: http://www.loc.gov/aba/pcc/rda/RDA%20Task%20groups%20and%20charges/ReportPCCTGonNameAuthInA_NonMARC_Environ_FinalReport.pdf****
>
>  ****
>
>  ****
>
> Survey to comment on the report: https://www.surveymonkey.com/s/PZQQPFF ****
>
>
>
>
>  ****
>
> Philip
>
> ****
>
> -- ****
>
> Philip E. Schreur****
>
> Chair, Program for Cooperative Cataloging****
>
> Head, Metadata Department****
>
> Stanford University****
>
> 650-723-2454****
>
> 650-725-1120 (fax)****
>
> **************************************************************************
> ****
>
> Experience the British Library online at www.bl.uk****
>
>  ****
>
> The British Library�s latest Annual Report and Accounts :
> www.bl.uk/aboutus/annrep/index.html****
>
>  ****
>
> Help the British Library conserve the world's knowledge. Adopt a Book.
> www.bl.uk/adoptabook****
>
>  ****
>
> The Library's St Pancras site is WiFi - enabled****
>
>  ****
>
> **************************************************************************
> ***
>
>  ****
>
> The information contained in this e-mail is confidential and may be
> legally privileged. It is intended for the addressee(s) only. If you are
> not the intended recipient, please delete this e-mail and notify the
> [log in to unmask] : The contents of this e-mail must not be disclosed or
> copied without the sender's consent. ****
>
>  ****
>
> The statements and opinions expressed in this message are those of the
> author and do not necessarily reflect those of the British Library. The
> British Library does not take any responsibility for the views of the
> author. ****
>
>  ****
>
> *************************************************************************
> ****
>
>  Think before you print****
>
>
>
> ****
>
> -- ****
>
> Philip E. Schreur****
>
> Chair, Program for Cooperative Cataloging****
>
> Head, Metadata Department****
>
> Stanford University****
>
> 650-723-2454****
>
> 650-725-1120 (fax)****
>
>


-- 
Stephen Hearn, Metadata Strategist
Technical Services, University Libraries
University of Minnesota
160 Wilson Library
309 19th Avenue South
Minneapolis, MN 55455
Ph: 612-625-2328
Fx: 612-625-3428