Print

Print


Hi Ray, all,

To clarify, this is *in addition to* the ability to just owl:sameAs the URI
identifier directly with the resource?  And the use case is that there's
*other* information that is desirable to express about the provenance of
the identifier, such as the organization that minted it?
If so, it would be good to show those properties as well.

For example:

<http://ld.stanford.edu/books/1> a bf:Work ;
  owl:sameAs <urn:isbn:123456789X> ;
  bf:identifier [ a bf:IdentifierDescription ;
      bf:scheme <http://id.loc.gov/isbn> ;
      bf:value "123456789X" ;
      bf:assigner <bowker.com> ;
      bf:uriFormOfIdentifier "urn:isbn:123456789X" ]

Yes?

Thanks!

Rob



On Mon, Aug 4, 2014 at 1: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
> <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
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>



-- 
Rob Sanderson
Technology Collaboration Facilitator
Digital Library Systems and Services
Stanford, CA 94305