The modeling of role in 2.2 has problems.  Will a single person playing
multiple roles be entered as multiple property statements for the same
resource, or will there be a way to specify multiple roles in the context
of a single property statement? Will BIBFRAME have an option for
unspecified or "other" role, given that the role terms appear to be part of
BIBFRAME's controlled vocabulary in Example 2?

The addition of Role as a BIBFRAME Authority resource mediating between a
Work and a Person in 3.2 would lead to requiring multiple BIBFRAME
Authorities for the same entity playing different roles. That runs counter
to the plan of having one BIBFRAME Authority per entity. Section 3.4
acknowledges this, but argues that multi-role cases (or at least those
resulting from anomalous data) will be a "very, very small percentage of
the whole"--but inevitably it will tend to be those named entities which
are most prolific which will turn out to have the most roles (and the most
anomalous roles in existing data), so dealing with these cases more
efficiently will still be a concern.

Rather than either of these, would it be possible instead to limit BIBFRAME
Work properties to Creator and Contributor (roughly reflecting the
distinction in Simplified Dublin Core and MARC's 1XX/7XX) and then allow
repeatable Type attributes or a Type attribute with multiple values for
those the Creator and Contributor properties to specify role more precisely
for a given entity's relationship to a resource? The Type attribute would
not be required, so if an agent's role has no controlled value, the agent
could still be named in relation to the Work in more general terms as a
Creator or Contributor. BIBFRAME Instance records might need to add another
general role term or two, but would leave more specific role terms to a
Type attribute.

The "bad data" case could be managed by defining a separate
"typeUnrecognized" attribute which could contain any text. To ensure better
control of "good data", the Creator/Contributor Type attributes might be
expanded into typeTerm, typeCode, and typeURI, each with declared
schema-level or implementation-level parameters.

Adding a new work in which someone named in an existing BIBFRAME Authority
has a new role should not require adding a new BIBFRAME Authority. Making
role part of the BIBFRAME Authority will place a burden on it which a
lightweight abstraction layer shouldn't have to carry.


On Wed, Aug 14, 2013 at 4:33 PM, Ford, Kevin <[log in to unmask]> wrote:

> Dear All,
> We wanted to share two documents with you all.  One is new, the other is
> an updated version.
> The BIBFRAME Use Cases and Requirements document "...specifies use cases,
> requirements, and objectives for BIBFRAME. It suggests how BIBFRAME
> supports a variety of traditional and forward looking uses cases, describes
> the communications environment for the use cases in BIBFRAME, and describes
> the model communication format and acceptable serializations. For each use
> cases, supporting requirements and design objectives are defined."
> The Use Case and Requirements document is not inclusive.  We fully
> anticipate adding to it.  In fact, we hope and expect the document will
> elicit additional use cases from the community.  But, besides new use
> cases, we encourage feedback about the ones detailed in the document.  It
> is accessible at:
> The second document is a significant revision of the /On BIBFRAME
> Authority/ discussion paper.  The current version reflects changes,
> additions, and deletions stemming largely from your feedback - thank you.
>  Although it has been slightly re-engineered toward acceptance of the
> "lightweight abstraction layer," the major issues - outlined in the
> previous version or raised from listserv comment - are still represented.
>  As before, we look forward to the discussion.  The revised version is
> available at:
> When starting a new topical thread about the papers, please start a create
> new email with a descriptive subject, such as "use cases -- web triggers,"
> "use cases -- authority reconciliation," or "authority -- direct approach."
> Yours,
> Kevin
> --
> Kevin Ford
> Network Development and MARC Standards Office
> Library of Congress
> Washington, DC

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