LISTSERV mailing list manager LISTSERV 16.0

Help for BIBFRAME Archives


BIBFRAME Archives

BIBFRAME Archives


BIBFRAME@LISTSERV.LOC.GOV


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Proportional Font

LISTSERV Archives

LISTSERV Archives

BIBFRAME Home

BIBFRAME Home

BIBFRAME  August 2014

BIBFRAME August 2014

Subject:

Re: bf:Identifier

From:

"[log in to unmask]" <[log in to unmask]>

Reply-To:

Bibliographic Framework Transition Initiative Forum <[log in to unmask]>

Date:

Tue, 5 Aug 2014 10:56:20 -0400

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (87 lines)

> bf:identifierScheme  becomes a resource (not a literal)
> Thomas Berger proposed this in one of his  messages, and it seemed well-reasoned.

Is there an intention to provide a class for the range of this predicate? For example, it could provide information about whether the scheme as it is used in the particular data at hand supports multiple assignation to resources or does not. It might be that there is a better vocabulary already available for the description of identifier schemes, and Bibframe could reuse or at least cohere with it. Or perhaps it's not really Bibframe's place to make assertions about identifier schemes… I'm not sure. In any event, I do think it might be well to offer a type here, for later optional expansion.

---
A. Soroka
The University of Virginia Library

On Aug 4, 2014, at 4:28 PM, "Denenberg, Ray" <[log in to unmask]> 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
>  
>  
>  
>  
>  
>  
>  

Top of Message | Previous Page | Permalink

Advanced Options


Options

Log In

Log In

Get Password

Get Password


Search Archives

Search Archives


Subscribe or Unsubscribe

Subscribe or Unsubscribe


Archives

December 2019
November 2019
October 2019
September 2019
August 2019
July 2019
June 2019
May 2019
April 2019
March 2019
February 2019
January 2019
December 2018
November 2018
October 2018
September 2018
August 2018
July 2018
June 2018
May 2018
April 2018
March 2018
February 2018
January 2018
December 2017
November 2017
October 2017
September 2017
August 2017
July 2017
June 2017
May 2017
April 2017
March 2017
February 2017
January 2017
December 2016
November 2016
October 2016
September 2016
August 2016
July 2016
June 2016
May 2016
April 2016
March 2016
February 2016
January 2016
December 2015
November 2015
October 2015
September 2015
August 2015
July 2015
June 2015
May 2015
April 2015
March 2015
February 2015
January 2015
December 2014
November 2014
October 2014
September 2014
August 2014
July 2014
June 2014
May 2014
April 2014
March 2014
February 2014
January 2014
December 2013
November 2013
October 2013
September 2013
August 2013
July 2013
June 2013
May 2013
April 2013
March 2013
February 2013
January 2013
December 2012
November 2012
October 2012
September 2012
August 2012
July 2012
June 2012
May 2012
April 2012
March 2012
February 2012
January 2012
December 2011
November 2011
October 2011
September 2011
July 2011
June 2011

ATOM RSS1 RSS2



LISTSERV.LOC.GOV

CataList Email List Search Powered by the LISTSERV Email List Manager