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
