Kate, I don't think that the problem is with primary responsibility, 
it's with limiting primary responsibility to *one* and only one "agent". 
We know that more than one person can have primary responsibility. So 
the "other agent" is the problem, especially because we rarely specify 
what kind of relationship that other agent has.

There is no reason why we cannot have an ordered list of equally 
responsible creators where that is the case. But there is a difference 
between "first named author" and "main entry" -- and although catalogers 
may be aware that the main entry is often the first named author, the 
user looking at a library catalog display can't be expected to know what 
it means that one and only one author *heading* is listed with the short 
display. And, no, I don't think that the "statement of responsibility" 
explains all, even if it's in the display.

The catalog record is cryptic to the point of being, as I've called it 
before, on the order of a secret language of twins, understood only by 
those who invented the language. I say that as a non-cataloger who has 
struggled to do the right thing with library data but who has often 
found that what was in the cataloger's mind is not coded as such in the 
data that I receive. This gets us back to the work title question, where 
$aHamlet, $aSelections, and $aSymphonies are identical from a 
machine-readable point of view, but obviously have deeply different 
meanings as well as different functions in relation to discovery. Now is 
the time to do what we can to make the machine-readable data better 
reflect the actual meaning of the bibliographic description. (Actually, 
the time was probably about 1990 when we moved from card to online 
catalogs, but that's water under the bridge.)


On 4/21/15 8:05 AM, Bowers, Kate A. wrote:
> Citation and common sense both demand that we identify primary 
> responsibility. Is it James Faulkner’s Hamlet, or Shakespeare’s 
> Hamlet?  You still need to say who or what has primary responsibility 
> for the darned thing!  If it’s really equally shared responsibility, 
> we should say so.  But primary responsibility is huge to scholars.
> Don’t even get me started on the need for primary responsibility for 
> Symphony No. 1.
> Kate
> *Kate Bowers*
> Collections Services Archivist for Metadata, Systems, and Standards
> Harvard University Archives
> [log in to unmask] <mailto:[log in to unmask]>
> 617.496.2713
> voice: (617) 384-7787
> fax: (617) 495-8011
> web:
> Twitter: @k8_bowers
> *From:*Bibliographic Framework Transition Initiative Forum 
> [mailto:[log in to unmask]] *On Behalf Of *Fallgren, Nancy 
> (NIH/NLM) [E]
> *Sent:* Tuesday, April 21, 2015 10:42 AM
> *To:* [log in to unmask]
> *Subject:* Re: [BIBFRAME] Work titles question
> Maybe we should belabor this point – if not now, when?
> And adding to your point, in RDA RDF there are properties  "has other 
> person, family, or corporate body associated with a work” (rdaw) and 
> "has other agent associated with a resource" 
> <> (rdau) – a clear 
> legacy of main entry, which hasn’t had real utility since we stopped 
> using card catalogs.  At what point do we let go of such outdated 
> practices and constraints and apply practices that reflect our current 
> environment?
> -Nancy
> Nancy J. Fallgren
> Metadata Specialist Librarian
> Cataloging and Metadata Management Section
> Technical Services Division
> National Library of Medicine
> *From:*Karen Coyle [mailto:[log in to unmask]]
> *Sent:* Tuesday, April 21, 2015 9:15 AM
> *To:* [log in to unmask] <mailto:[log in to unmask]>
> *Subject:* Re: [BIBFRAME] Work titles question
> I missed "bf:authorizedAccessPoint" - which does exist. I should have 
> looked online rather than in my downloaded files. Still, it is unclear 
> what the meaning and function of access points are in bibliographic 
> data in RDF. Access points were literally "access points". But they 
> also had a collocation function. In fact, access was through 
> collocation/alphabetical listing. The "work" access point often 
> combines work and expression
>    [Hamlet. French]
> I can see how some access points could be considered identifiers, but 
> that hasn't been their function -- their function really has been as 
> access points. And if you need to access Hamlet in French in a 
> machine-readable world it should be possible without a [Hamlet. 
> French] access point.
> It's not worth belaboring this particular point, but it's another 
> example of how we need to do more than just blindly copy over 
> practices from MARC to any future format.
> kc
> On 4/20/15 4:54 PM, Ehlert, Mark K. wrote:
>     *From:*Bibliographic Framework Transition Initiative Forum
>     [[log in to unmask] <mailto:[log in to unmask]>] on
>     behalf of Karen Coyle [[log in to unmask] <mailto:[log in to unmask]>]
>     Thanks, Stephen. The access point info is particularly interesting
>     because neither RDA in RDF, nor BIBFRAME, nor FRBR in RDF have
>     *any* properties for authorized access points. All three do have
>     something that is essentially "title of the work." With your reply
>     it is now entirely unclear to me what information should be
>     encoded as "title of the work" as well as whether there is any
>     place for access points in these vocabularies.
>     *  *  *  *  *
>     I can't speak for BIBFRAME, but in FRBR and RDA, an access point
>     is not defined as an entity.  In fact, it didn't come out as an
>     entity (with attributes) until FRAD came along--"controlled access
>     point" it's called there.  An access point as viewed through RDA's
>     prism is an artificial construct that acts as a substitute
>     identifier, though not defined as an identifier per se.  Still, if
>     I read the RDA Registry correctly, access points for works would
>     latch onto the "has identifier for the work" property:
>     -- 
>     Mark K. Ehlert
>     University of St. Thomas
> -- 
> Karen Coyle
> [log in to unmask]  <mailto:[log in to unmask]>
> m: +1-510-435-8234
> skype: kcoylenet/+1-510-984-3600

Karen Coyle
[log in to unmask]
m: +1-510-435-8234
skype: kcoylenet/+1-510-984-3600