On 8/5/14, 12:18 AM, Juha Hakala wrote:
>> #2
>> LCCN permalink:*
>> *
>> <> a bf:Instance ;
>>       bf:identifier   
>> <> .
>>   <>
>> a bf:IdentifierDescriptor ;
>> **bf:identifierScheme*                                     
>> <* 
>> <>*> ;*
>> **bf:identifierValue*                                
>> "****" ; *//or 010 format?**
>> **bf:uriFormOfIdentifier                   
>> “*”.*
>> **
>> 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). 
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:

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):

   <datafield  tag="010"ind1="  "ind2="  ">
     <subfield  code="a">    65026236</subfield>

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]
m: 1-510-435-8234
skype: kcoylenet