[log in to unmask]" type="cite">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.
From: Bibliographic Framework Transition Initiative Forum <[log in to unmask]> on behalf of Shelley Doljack <[log in to unmask]>
Reply-To: Bibliographic Framework Transition Initiative Forum <[log in to unmask]>
Date: Friday, November 6, 2015 at 1:14 PM
To: "[log in to unmask]" <[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?
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.
Discovery Metadata Librarian
Metadata Dept., Lathrop Library
Stanford University Libraries
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:
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
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