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:

bf:identifier http://lccn.loc.gov/56014046

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:

http://dx.doi.org/10.978.12345/99990

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)"^^http://id.loc.gov/id/gpoin

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

kc

[1] http://www.doi.org/factsheets/ISBN-A.html

On 8/1/13 11:12 AM, Trail, Nate wrote:

[log in to unmask]" type="cite">

All,

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

or

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?

Thanks,

Nate

-------------------------------------------

Nate Trail

-------------------------------------------

LS/TECH/NDMSO

Library of Congress

202-707-2193

[log in to unmask]

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