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:
>
> 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] <mailto:[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
