You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The 7xx fields should process OCLC control numbers w/ bf:Local identifiers into the subfield $w like LCCNs not in the $o which is for actual local identifiers.
The way it seems to work now is they only process correctly if they are bf:Identifiers w/o a subclass, and that have an agent with a bf:code and no uri.
If you are 'getting' bf for processing linking fields, you would probably use the 2nd form so the logic should know about processing this shape as well:
prefix (OCoLC)
concatenated with the rdf:value,
formatted as a number so no leading letters and no leading zeros.
The text was updated successfully, but these errors were encountered:
The 7xx fields should process OCLC control numbers w/ bf:Local identifiers into the subfield $w like LCCNs not in the $o which is for actual local identifiers.
The way it seems to work now is they only process correctly if they are bf:Identifiers w/o a subclass, and that have an agent with a bf:code and no uri.
Correct:
(OCoLC)2256995
Aka the 777 produced by this exemplar shape:
But if you go to the instance in id (https://id.loc.gov/resources/instances/11165447.html) it has this shape:
If you are 'getting' bf for processing linking fields, you would probably use the 2nd form so the logic should know about processing this shape as well:
prefix (OCoLC)
concatenated with the rdf:value,
formatted as a number so no leading letters and no leading zeros.
The text was updated successfully, but these errors were encountered: