Nate, I'd vote for #1, using URIs, and in particular http URIS, where they exist. We have to consider the potential number of identifiers to be unlimited, so option #2 does not scale. Also, more and more identifiers should be in the URI form in the future, and the whole "longer than past" thing applies.

How to indicate what the identifier is in the cases where there is no URI is the tricky part. The easy URI case would be:


Note that DOI has taken on the URI-izing of the ISBN,[1] although I do not think I have seen it used in the wild:

As I said in my note to Robert, it makes sense to me for LC to create LC-specific codes for the identifiers that do not have a URI form provided by the issuing agency. So for something like the GPO item number, you could create:

    bf:identifier " 277-A-2 (MF)"^^

or something like that. You get the point. Then it would be clear who is asserting the identifier.



On 8/1/13 11:12 AM, Trail, Nate wrote:
[log in to unmask]" type="cite">



We're thinking about modeling identifiers (and other properties?) in two ways:


1) generic property with a more specific data type:


                bf:identifer  "9780394856308"^^http://example/org/isbn13




2) specific property:

                                               bf:isbn13 "9780394856308"


where 'bf:isbn' is a subproperty of 'bf:identifier'.


How does the community feel about these two options, and why?







Nate Trail



Library of Congress


[log in to unmask]

Karen Coyle
[log in to unmask]
ph: 1-510-540-7596
m: 1-510-435-8234
skype: kcoylenet