-----Original Message-----
From: Bibliographic Framework Transition Initiative Forum
[mailto:[log in to unmask]] On Behalf Of Stephen Hearn
Sent: Thursday, August 15, 2013 6:15 PM
To: [log in to unmask]
Subject: Re: [BIBFRAME] Authority - Treatment of role data
The option of listing the same name in two role properties for the
same resource is a reasonable solution to the multi-role problem,
especially if there's a way to assign a name to a less or
un-specified or an invented role property. It also keeps the role
specification in the BIBFRAME Work where I think it belongs.
I still worry that it might lock down the vocabulary for describing
role with BIBFRAME, assuming "author" and "illustrator" in the
example are BIBFRAME properties. Having native BIBFRAME define a more
limited set of generic relationship categories and letting a type
attribute with a declared source vocabulary determine what the role
terms/codes are used in a given implementation seems more flexible.
Stephen
On Thu, Aug 15, 2013 at 4:28 PM, Ford, Kevin <[log in to unmask]> wrote:
Dear Stephen,
Thanks for the comments. A few answers and comments of my own follow:
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?
-- The document does not include an example of this, but here is one:
<!-- BIBFRAME Work -->
<Book id = "http://bibframe/work/the-garden-of-abdul-gasazi">
<title>The garden of Abdul Gasazi</title>
<author resource = "http://bibframe/auth/person/chris-van-allsburg"
/>
<illustrator resource = " http://bibframe/auth/person/chris-van-
allsburg" /> </Book>
<!-- BIBFRAME Authority -->
<Person id="http://bibframe/auth/person/chris-van-allsburg ">
<authorizedAccessPoint>Van Allsburg,
Chris</authorizedAccessPoint>
<hasAuthority
resource="http://id.loc.gov/authorities/names/n79071437" /> </Person>
Two (defined) role properties on the Work both point to a single
Person Authority.
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?
-- Yes.
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.
-- There would be a separate Role resource for every role, but there
would be only one BIBFRAME Authority per entity. If this isn't
clear, I can work up a more detailed example.
Section 3.4
-- About section 3.4: For starters, I'll probably rename it Anomalous
Data in a revision. Good word, wish I had thought of it. To be
clear, I don't like what's being proposed, but in the interest of a
simpler, future solution I worry about adopting a overly complicated
approach (which, I believe, is what the Role proposal is) in order to
accommodate anomalous data, which is, on the whole, a small
percentage of existing data and, if we can envision better cataloging
interfaces in the future, I would hope a non-existent issue. I'm
also not crazy about two different approaches; when it comes to
exchange and comprehension, we'll all benefit from a single solution
(even if it isn't perfect in 100% of cases).
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?
-- In many ways what you are proposing here is the Role resource
avenue, especially when you start talking about typeTerm, typeCode,
and typeURI attributes/properties. But, before we continue this
conversation, I have two quick questions for you:
1) Does my example above - demonstrating how to relate one Person
Authority with multiple roles to a Work - impact your questions?
2) What is it *you* want to do? I ask because I started to wonder
what benefit you saw in limiting Work properties to Creator and
Contributor followed by a whole typing system.
Yours,
Kevin
-----Original Message-----
From: Bibliographic Framework Transition Initiative Forum
[mailto:[log in to unmask]] On Behalf Of Stephen Hearn
Sent: Thursday, August 15, 2013 2:26 PM
To: [log in to unmask]
Subject: [BIBFRAME] Authority - Treatment of role data
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.
Stephen
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:
http://bibframe.org/documentation/bibframe-usecases/
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:
http://bibframe.org/documentation/bibframe-authority/
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
--
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