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