Print

Print


Hi, Ray. Can we assume that this solution is being offered for all of 
the identifiers in the id.loc.gov vocabulary? [1]

If so, I think it would be good to see a few more examples. There are 
identifiers with defined URNs (like ISBN), some with no URN, and some 
with http IRIs.

Here's a stab at two different examples, mostly copied from your 
example. The first has no URN, the second has an http IRI:

#1
MARC:
*027* 	*##**$a*FYHU/PF/2--80/12+MAGN


BIBFRAME:

<http://example.com/xyz/book1> a bf:Instance ;

       bf:identifier   
<http://example.com/xyz/identifiers/book1/identifier1> .

   <http://example.com/xyz/identifiers/book1/identifier1>

a bf:IdentifierDescriptor ;

**bf:identifierScheme*                                     
<*http://id.loc.gov/vocabulary/identifiers/ 
<http://id.loc.gov/vocabulary/identifiers/isbn>strn*> ;*

**bf:identifierValue*                                
"*FYHU/PF/2--80/12+MAGN*" .
*


#2
LCCN permalink: http://lccn.loc.gov/65026236*
*


<http://example.com/xyz/book1> a bf:Instance ;

       bf:identifier   
<http://example.com/xyz/identifiers/book1/identifier1> .

   <http://example.com/xyz/identifiers/book1/identifier1>

a bf:IdentifierDescriptor ;

**bf:identifierScheme*                                     
<*http://id.loc.gov/vocabulary/identifiers/lccn 
<http://id.loc.gov/vocabulary/identifiers/isbn>*> ;*

**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?

Thanks,
kc
[1] http://id.loc.gov/vocabulary/identifiers 
<http://id.loc.gov/vocabulary/identifiers/isbn>

On 8/4/14, 1:28 PM, Denenberg, Ray wrote:
>
> Discussion about identifiers has been interesting and valuable, and 
> here at LC we are trying to capture the essence of the discussion. As 
> part of that process,  we have a proposal for consideration, for a 
> slightly different modeling of bf:Identifier.
>
> Let’s say I have an identifier – an isbn – for an Instance.   I 
> propose to represent it like this:
>
> <http://example.com/xyz/book1> a bf:Instance ;
>
>       bf:identifier   
> <http://example.com/xyz/identifiers/book1/identifier1> .
>
>   <http://example.com/xyz/identifiers/book1/identifier1>
>
> a bf:IdentifierDescriptor ;
>
> **bf:identifierScheme*                                     
> <http://id.loc.gov/vocabulary/identifiers/isbn> ;*
>
> **bf:identifierValue*                                
> "**9780099483793**" ;*
>
> **bf:uriFormOfIdentifier “/urn:isbn:/*9780099483793”.***
>
> **
>
> *Summary:*
>
> *·**bf:Identifier becomes bf:IdentifierDescriptor.*
>
> ·bf:identifierScheme becomes a resource (not a literal).
>
> ·bf:uriFormOfIdentifier is introduced.
>
> **
>
> *A couple notes:*
>
> *·**Note the use of property bf:identifier, not bf:isbn. Included as 
> part of this proposal is to abolish all of the bf:indentifier 
> subproperties – bf:isbn, bf:issn, etc. (as we have already agreed to 
> abolish bf:uri).*
>
> *·**Note also that this representation violates the tentative 
> agreement that we would always represent a bf:Identifier (changed to 
> bf:IdentifierDescriptor in this proposal)  as a blank node.  I think 
> the reasoning behind that no longer applies, with this proposal.*
>
> **
>
> *Discussion*
>
> *bf:Identifier becomes bf:IdentifierDescriptor*
>
> *Part of the confusion has been that people see*
>
> **
>
>   <http://example.com/xyz/identifiers/book1/identifier1>   a     
>                 bf:Identifier ;
>
> and conclude that http://example.com/xyz/identifiers/book1/identifier1 
> is an identifier. And justifiably so, but they get confused:
>
> ·Some mistakenly think that it is an identifier for the resource 
> (book1) when really it is an RDF identifier, for the resource 
> bf:Identifier.
>
> ·Some say “it’s an identifier for an identifier  (i.e. the 
> bf:Identifier) which is an un-necessary layer of indirection”.
>
> but if you portray bf:Identifier as an “identifier description” rather 
> than an identifier, then there is less confusion, and the way to do 
> that would be to change its name from bf:Identifier to 
> bf:IdentifierDescriptor.
>
> **
>
> **
>
> *bf:identifierScheme  becomes a resource (not a literal)*
>
> Thomas Berger proposed this in one of his  messages, and it seemed 
> well-reasoned.
>
> *bf:uriFormOfIdentifier  introduced*
>
> In the debate about what form the identifier should take - string or 
> URI --  and if URI what does that imply (must it resolve?) – I believe 
> (correct me if I’m wrong) the consensus is to  supply:
>
> (1)the raw string identifier,
>
> (2)the scheme that it is supplied  in,  and
>
> (3)*what it looks like when turned into a URI* (if it can be turned 
> into a URI) – *supplied as a string,* not a resource.
>
> And the user can choose which one to use, the combination raw string 
> plus scheme, or the URI.   We don’t say that this URI is an identifier 
> for the resource, and we don’t say it isn’t; we simply say, here is 
> the URI form for this identifier.
>
> In the example above the URI is a URN, however any URI scheme could 
> apply, urn:, info:, http:, etc.
>
> Yes, even http:      ……
>
> In one of Rob’s messages he gave the example:
>
> bf:identifierValue "http://linked-data.stanford.edu/titles/books/1234"
>
> Which I tried to make sense of (which in turn led to the above 
> proposal) and I asked, can you separate that into an identifier 
>  scheme and a value within that scheme and Rob’s response was  ‘The 
> scheme is http://linked-data.stanford.edu/titles/books/ and the 
> identifier is “1234” ‘
>
> So for Rob’s example:
>
> **bf:identifierScheme*                                     
> <*http://linked-data.stanford.edu/titles/books/*> ;*
>
> **bf:identifierValue*                                "**1234**" ;*
>
> **bf:uriFormOfIdentifier 
> “http://linked-data.stanford.edu/titles/books/1234*”.***
>
> So, there is no real reason to exclude http URIs when used in this manner.
>
> Comments welcome!
>
> Ray
>

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