We appreciate the comments and discussion on the three proposals.  I want to respond to a few points raised on the identifier proposal and I will follow up on the other two proposals later.

First, some background.  Though these proposals were developed at LC, we did consult with a number of RDF/Linked Data experts, and we even had them review early drafts. Their review and analysis  improved the proposals; we accepted most of their recommendations, but not all, as we felt some of these issues might be better debated over the public list.  I won’t identify these consultants by name but they know who they are and are free to identify themselves on their own and to disagree with any aspects of these proposals.

I’ve singled out three issues with identifiers: (1) normalization, (2) identifier classes, (3) the use and semantics of property bf:identifiedBy.

Normalization

All I can do is acknowledge that it is an important issue, that it is not at all addressed by the proposal,  and that we have not yet given it sufficient thought.

Identifier Classes

Thomas Berger [log in to unmask] Wrote:

However reuse of the http://id.loc.gov/vocabulary/identifiers is not a good idea, even for an example, since that describes a collection of rdf:property.

Sorry, I Should have mentioned: if this proposal is adopted, the plan is to redefine http://id.loc.gov/vocabulary/identifiers as classes.

Furthermore, we discussed yesterday that perhaps we went too far when removing all the identifier properties by not defining (within the BF namespace) corresponding identifier classes.  There are currently 35 or so identifier properties, all to be removed, and we don’t want to define 35 or so corresponding classes.   But we think it is worth considering defining a handful, maybe ten classes, and then add additional classes incrementally when the need for them is demonstrated.

bf:identifiedBy

bf:identifiedBy was originally suggested as a replacement for bf:identifier, during one of the list discussions on identifiers. (Actually, bf:hasIdentifier was first suggested as a replacement for bf:identifier but then bf:identifiedBy was suggested and it seemed to be preferred over bf:hasIdentifier.)   Now, bf:identifier is used for string identifiers only, so one might assume that bf:identifiedBy is also for string identifiers only, and the identifier proposal only talks about string identifiers so that would be a reasonable assumption.  But that assumption was not intended, rather, the proposal was intentionally silent on whether bf:identifiedBy was merely a replacement for bf:identifier of a generalization of bf:identifier to be used as described in the subsequent role and authority proposals.  We apologize for confusion this may have caused.

So the question becomes: there is a resource, for example, an agent (a person), identified (or “described”) by an RDF resource.  Should we say:

bf:agent [bf:identifiedBy      <URI for RDF resource for the Agent>  ] .

Or, should there be a different BIBFRAME property for this usage?

Although I am focusing currently on the identifier proposal, this question is more relevant to the other two proposals, and I haven’t yet caught up with them; however I have skimmed through them and it seems that there are good arguments on both sides of this question.  I consider this an open question for now.

… a word about the role proposal.  As I said I have only skimmed the proposal, and I’ll have more to say, hopefully soon.  But I will say this:  I very much like the suggestion (from Steven Folsom)  to rename “contributor” to “contribution” and think that it could clear up a good deal of the confusion.

Ray Denenberg

Library of Congress