LCCNs have a normal form that is defined here:
Normalization includes stripping blanks, removing everything after trailing '/' , and expanding wildcard '-' characters into 0 (for pre-Y2K numbers).
Using these normalized numbers in 010 fields is a matter of placing the prefix at the start of the field, filling in any unused prefix chars with spaces, then appending the number.
See the MARC 21 spec here for the skinny (it's the same for the other formats).
It is a good idea to normalize all LCCNs before comparing them (the v'ger derivative that handles authorities.loc.gov had some weird errors due to non-normalized LCCNs with trailing blanks).
(Note that this field is not ready for the Y10K problem.)
On 8/5/14, 12:18 AM, Juha Hakala wrote:
Juha, I agree, although it may depend on the origin of the data. If one is starting with a MARC record, an LCCN may have the form:
LCCN permalink: http://lccn.loc.gov/65026236
<http://example.com/xyz/book1> a bf:Instance ;
bf:identifier <http://example.com/xyz/identifiers/book1/identifier1> .
a bf:IdentifierDescriptor ;
bf:identifierScheme <http://id.loc.gov/vocabulary/identifiers/lccn> ;
bf:identifierValue "http://lccn.loc.gov/65026236" ; //or 010 format?bf:uriFormOfIdentifier “http://lccn.loc.gov/65026236”.
Is this how you think these identifiers would be represented?
IMO it would be more logical to have bf:identifierValue "65026236" since that is the LCCN. Actionable version of the identifier (LCCN permalink) belongs to bf:uriFormOfIdentifier (or bf:urlFormOfIdentifier; see below).
010 __ |a gm 71005662
That includes spaces, and all LCCNs that do not have a prefix ("gm") have leading spaces (example from MARCXML because multiple spaces are removed in HTML display):
LC has compressed spaces out of the URIs for these same identifiers. Therefore if you are starting with an LC "Permalink" it may take some effort to reconstruct the original LCCN. But these URI permalinks only exist in LC online products, not in the many millions of MARC records in library catalogs around the globe. I don't know if this matters, just that you may not always have access to both and it isn't clear if it's worth while to go to the effort of including both forms if you have to derive them from what you have.
It seems that the most practical thing is to include the data you have on hand, and not require that all of the properties are included. That would mean that you could have an identifierValue but not a URI form, or vice versa. It would be good to look at this from the view of a non-LC, non-US, non-MARC21 library system.
-- Karen Coyle [log in to unmask] http://kcoyle.net m: 1-510-435-8234 skype: kcoylenet