At the moment, BF has a property for "identifierStatus", presumably to 
carry the information that is now in the MARC $z of many identifier fields.
$z - Canceled/invalid

In the serials area it is more complex, as the ISSN has:

$m - Canceled ISSN-L (R)
$y - Incorrect ISSN (R)
$z - Canceled ISSN (R)

As a qualifier on the identifier, this means that many uses of the 
identifier need to check the qualifier to see if the identifier is valid 
because they will only want to operate on valid identifiers (e.g. for 
linking). That strikes me as a bad idea, especially since the vast 
majority will be valid.

Another option is to treat the invalid/etc. identifiers as separate 
properties, with their own relationship to the entity identified, or 
with a relationship to a specific identifier. (The MARC format 
unfortunately tends to have in the same field subfields that qualify the 
focus of the cataloging (the book, the journal) and subfields that 
qualify or relate to other subfields in the field. So one has to decide 
whether the ISSN-L has a direct relationship to the ISSN or has a direct 
relationship to the serial, and the same for invalid and canceled 
identifiers. )


On 8/27/15 11:26 AM, Denenberg, Ray wrote:
> 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] <mailto:[log in to unmask]> Wrote:
> However reuse of the 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 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

Karen Coyle
[log in to unmask]
m: +1-510-435-8234
skype: kcoylenet/+1-510-984-3600