Print

Print


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