-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Am 04.08.2014 22:28, schrieb Denenberg, Ray:
>
> 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).

Fine. Outside of Bibframe people still can plaster their resources
directly with more straightforward properties like

mymarc:isbn13 "9780099483793" ;


> · 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.

Agreed. Also the content of such an bf:IdentifierDescriptor usually
is not exhaustive, I might add

 bf:identifierValue "978-0-09-948379-3", " 0-09-948379-3";

and
  bf:uriFormOfIdentifier "URN:ISBN:0-09-948379-3".

to the bf:identifierDescriptor given above.
(apart from ISBN10/ISBN13 issues the forms showed in the example
are not the preferred forms by the respective standards, but maybe for
some community)




> 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.

except that (1) and (3) must allow for multiple values, the equivalence rules
(i.e. what will be acceptable within the same IdentifierDescriptor) are
established by knowing (2).

I would abstain from coding degrees of preference for the identifierValues
and uriFormOfIdentifer found in bf:IdentifierDescriptors, however I would
expect that some will operate with specific data types as restriction of
xsd:normalizedString / xsd:anyURI.


> 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.

Yes.

Establishing that <http://example.com/xyz/book1> /is/ <URN:ISBN:0-09-948379-3>
should be reserved to an explicit statement (which happens to be valid when we
consider the definition of bf:Instance, the semantics laid down for the urn:isbn
namespace and the evidence recorded in the bf:identifierDescriptor)

I would like to adopt the view that real world identifiers (as captured in
bf:identifierDescriptor resources) have an important role in /matching/
resources, but they do not directly /identify/ them in the semantic web sense
of "identifier" expressed in the concepts and naming of IRI / URI.

Perhaps the relabeling from bf:identifier to bf:identifierDescriptor has
still to much "identifier" in it, but "descriptor" alone is way to generic
to carry the intended meaning and some of the newer standards like ISNI or
ISIL do call themselves "identifiers" and not "numbers" any more...


viele Gruesse
Thomas Berger
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iJwEAQECAAYFAlPguNcACgkQYhMlmJ6W47O5SgQAkNAW7ZDLScBYZEdYU5uf715z
ortqdXnRAckwOw93wvQDKPnGszewY+fwlB3Wz5Ep94t/+ALYglskKx62XvzUGm6f
eFN+MEpU0LnCyQVPHjo5cgAkqHTk4P3AHE3zxvQgDUfUO1kXxvvm6kpcpMbMlEE9
OSMLTfmKw2bVPIW1d0g=
=oZ3b
-----END PGP SIGNATURE-----