Steven – Regarding the suggestion to use PROV: i suppose I am in the camp that wants to avoid over-engineering and excess complexity and so I am wary of introducing PROV into BIBFRAME.  I admit that I have not read the standard, but it is one of those massive W3C specs, and I wonder who among us has read and understands it.  If anyone has, please weigh in.

Ray

From: Bibliographic Framework Transition Initiative Forum [mailto:[log in to unmask]] On Behalf Of Steven Folsom
Sent: Thursday, August 27, 2015 5:20 PM
To: [log in to unmask]
Subject: Re: [BIBFRAME] role proposal

From: Bibliographic Framework Transition Initiative Forum on behalf of "Denenberg, Ray"
Reply-To: Bibliographic Framework Transition Initiative Forum
Date: Thursday, August 27, 2015 at 4:55 PM
To: "[log in to unmask]"
Subject: [BIBFRAME] role proposal

A  few points on the role proposal.

One of the issues is whether we can say :

        bf:agent [bf:identifiedBy  <agent resource> ]

and Thomas Berger points out that “objects of bf:identifiedBy are of class bf:Identifier,” (implication being that bf:identifiedBy has range bf:Identifier)  so you can’t do that. 

However, as I noted in my previous message (Identifier proposal) it is still open to debate  whether bf:identifiedBy is merely a replacement for or generalization of  bf:identifier.  If the latter, then bf:identifiedBy would no longer have range bf:Identifier, and so the above would be allowed.

Along these lines is the question of whether we can further contract the above to (Karen’s example):

   bf:agent   <http://id.loc.gov/authorities/names/1234> 

And again it depends on how/whether we define a range for bf:agent.  If we define the range to be class bf:Agent, then no, we cannot.  I think most of us are inclined not to want to restrict the vocabulary in this manner, and to allow such a contraction.

Steven Folsom notes that bf:contributor sounds like it’s an agent, when really it is a combination of a role and agent, and might be better named bf:contribution.   I like that suggestion.

However, it does present one limitation - the proposal does allow for this contraction:

      bf:contributor  <agent resource>

You could use the contraction above in bold and just model contributor sub-properties. The cost of this over an event –based pattern is that you can’t specify when or where the agent performed the contribution.

which could be useful when you want to say that an agent is a contributor, without specifying a role.

It would not make sense to say:

      bf:contribution  <agent resource>

because it sounds too much like an agent is a contribution.  However, perhaps we can live with this limitation.

So, changing contributor to contribution and repurposing contributor, we might say:

   bf:contribution

           [  bf:contributor  <agent resource> ;

              bf:role              <role resource> ]

and if no role is to be specified:

bf:contribution

           [  bf:contributor  <agent resource> ]

Right, and if somewhere along the way we figure out the role, we can add it. Again, if we’re going to use event-based patterns… I would consider reusing PROV-Activities. :)

Ray Denenberg

Library of Congress