Print

Print


You can bring out or leave out creator-ness based on the vocabulary you 
use. In the RDA element set, "is author of" 
http://www.rdaregistry.info/Elements/u/#P60663 is a subproperty of "is 
creator of", while "is performer of" is a subproperty of "is contributor 
of". So using RDA elements, there is no need to add a secondary relator 
term for a creator. On the other hand, if you use a flat list such as 
the MARC relators, the term is neutral as to whether it is a creator or 
a contributor. In that case, if you wanted to define these, you would 
need the extra creator/contributor term.

However, the neutrality can be good. What constitutes a creator vs a 
contributor is not a simple split, and is controversial even within the 
"traditional" cataloging community (RDA notwithstanding), particularly 
in specialist domains such as a-v and sound recording cataloging. These 
groups may welcome not having to assign or emphasize the 
creator/contributor split. Including all roles under bf:contributor also 
makes for simpler queries.

Nancy


On 11/6/2015 10:54 AM, Steven Folsom wrote:
> Shelley,
>
> The way I read the proposal, it allows you to express the 
> "creator-ness" through roles and/or direct relationships. The property 
> short-cut method is offered when the proposal suggests that you could 
> use external properties, see example #3. So maybe in the case you 
> describe, the following property might be appropriate— 
> http://rdaregistry.info/Elements/u/P60672
>
> I’m in favor of the Contribution/Role pattern because it allows us to 
> say more about the role (if we want/need to). Say you want to capture 
> that a book has two authors. The extra Contribution node can allow you 
> to rank them through a property like vivo:rank. Otherwise it’s 
> impossible to do ordering for two agents with the same shortcut 
> property to given work. With the extra node, we could also say that 
> the Contribution or Provision was made at a particular time and place.
>
> If the proposal to use roles with the Contribution/Provision pattern 
> stands, it would be ideal if bf:role was an object property with an 
> undefined range. If we are worried about what to do when a cataloger 
> wants to use a role that currently isn't defined, systems could create 
> a bnode with an rdfs:label with the new role label value. Better would 
> be a local URI for the newly defined role and to have a process for 
> suggesting it be made a “global” role.
>
> Alternatively we/LOC could be easy to recreate MARC/RDA relators as 
> Contribution/Provision sub-classes, e.g.
> mrc:author + bf:Contribution would become bf:AuthorContribution, or 
> mrc:publisher + bf:Provision would become bf:PublisherProvision.
>
> A smaller thing— The proposal uses “bf:Contributor” in the 2.0 
> Proposal (bullet number 4). Is this a typo or are there two classes 
> Contribution and Contributor? Hopefully only the former.
>
> respectfully,
> Steven
>
>
> From: Bibliographic Framework Transition Initiative Forum 
> <[log in to unmask] <mailto:[log in to unmask]>> on 
> behalf of Shelley Doljack <[log in to unmask] 
> <mailto:[log in to unmask]>>
> Reply-To: Bibliographic Framework Transition Initiative Forum 
> <[log in to unmask] <mailto:[log in to unmask]>>
> Date: Friday, November 6, 2015 at 1:14 PM
> To: "[log in to unmask] <mailto:[log in to unmask]>" 
> <[log in to unmask] <mailto:[log in to unmask]>>
> Subject: [BIBFRAME] Agents and Roles -- RE: BIBFRAME vocabulary 2.0 
> draft specifications posted
>
>     I’m not sure I quite understand the proposal for how to express a
>     creator role if bf:creator is removed. Let’s say, I have a person
>     who is the principal investigator of a resource, and we want to
>     specify that role as a creator role. There are also other people
>     involved in the creation of the resource, which we give the roles
>     author or creator to. How would I express that the principal
>     investigator is a creator too? Like this?
>
>     bf:contributor [
>
>         a bf:Contribution ;
>
>         bf:role “creator” ;
>
>         bf:role “principal investigator”;
>
>     bf:agent <URI#RWO> ] .
>
>     So basically, in order to specify that a person had a
>     creation-type role for a resource, I need to use an additional
>     role term (i.e. “creator”). Is that what is being proposed? If so,
>     in my experience trying to specify creator-type and
>     contributor-type roles in our MODS records, lacking the ability to
>     specify that a name is a creator-type in the schema makes it
>     challenging. We end up doing the same thing that I think is being
>     proposed here: use the role term “creator” in addition to other
>     role terms. I don’t really like this solution as I think being
>     able to specify a creator-type is more elegant. What is the
>     thinking behind removing bf:creator? Specifying a creator-type is
>     necessary for our data consumers to index and display things the
>     way the content owners expect their resources to display in the
>     discovery environment.
>
>     Shelley Doljack
>
>     Discovery Metadata Librarian
>
>     Metadata Dept., Lathrop Library
>
>     Stanford University Libraries
>
>     650-725-0167
>
>     [log in to unmask] <mailto:[log in to unmask]>
>
>     *From:* Bibliographic Framework Transition Initiative Forum
>     [mailto:[log in to unmask]] *On Behalf Of *McCallum, Sally
>     *Sent:* Tuesday, November 03, 2015 9:06 AM
>     *To:* [log in to unmask] <mailto:[log in to unmask]>
>     *Subject:* BIBFRAME vocabulary 2.0 draft specifications posted
>
>     BIBFRAME 1.0 has been stable for more than a year now. We have
>     intentionally kept it stable so that implementers could experiment
>     with it and so that we could learn from discussion and
>     consultation the issues of the vocabulary and how it might be
>     improved.  We at LC implemented a pilot that is ongoing now using
>     the 1.0 vocabulary – an exercise that also gave us “feedback”.
>
>     Then several months ago, LC started posting for review proposed
>     changes to the BIBFRAME vocabulary in preparation for its
>     redevelopment as BIBFRAME 2.0.  The change proposals were prepared
>     after reviewing the comments received on the listserv over the
>     last year and comments from invited experts – along with dealing
>     with our own implementation experiences.  Discussion of these
>     proposals and consultations proved quite fruitful and helped
>     significantly in the development of the draft 2.0 specification.  
>     We thank you all for your comments and advice.
>
>     We are referring to the current vocabulary in use as BIBFRAME 1.0
>     and the developing draft vocabulary as BIBFRAME 2.0.  There are
>     seven “draft specifications” (targeted at different components of
>     the vocabulary) posted at http://www.loc.gov/bibframe/docs/ .
>     Specifically:
>
>     Titles
>     <http://www.loc.gov/bibframe/docs/pdf/bf2-draftspectitles-10-29-2015.pdf>
>
>
>     Agents and Roles
>     <http://www.loc.gov/bibframe/docs/pdf/bf2-draftspecagentsroles-10-29-2015.pdf>
>
>
>     Items
>     <http://www.loc.gov/bibframe/docs/pdf/bf2-draftspecitems-10-29-2015.pdf>
>
>
>     Events
>     <http://www.loc.gov/bibframe/docs/pdf/bf2-draftspecevents-10-29-2015.pdf>
>
>     Identifiers and Notes
>     <http://www.loc.gov/bibframe/docs/pdf/bf2-draftspecidsnotes-10-29-2015.pdf>
>
>     Administrative Metadata
>     <http://www.loc.gov/bibframe/docs/pdf/bf2-draftspecadmin-10-29-2015.pdf>
>
>     Categories
>     <http://www.loc.gov/bibframe/docs/pdf/bf2-draftspeccategories-10-29-2015.pdf>
>
>     We invite comment and discussion on these draft specifications. 
>     Working from these specs, we hope to have BIBFRAME 2.0 in place
>     soon, hopefully by early January.
>
>     ***********************************
>
>     Sally H. McCallum
>
>     Chief, Network Development and MARC Standards Office
>
>     Library of Congress, 101 Independence Ave., SE
>
>     Washington, DC 20540  USA
>
>     [log in to unmask] <mailto:[log in to unmask]>
>
>     Tel: 1-202-707-5119 – Fax 1-202-707-0115
>
>     ***********************************
>


-- 
Nancy Lorimer
Head, Metadata Dept
Stanford University Libraries
[log in to unmask]
650-725-8819