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



Am 24.07.2014 00:36, schrieb Simeon Warner:

> URI Identifier Use Case 1: "I want to assert that another URI identifies the
> same resource and have this work well in LOD". In this case owl:sameAs is
> clearly the useful/practical way to implement and follows common LOD practice
> (as Rob suggests).
> 
> URI Identifier Use Case 2: "I want to describe the origins, provenance, etc. of
> a URI (in a similar way to other forms of identifier)". This use case is not
> supported by simple owl:sameAs suggestion. The problem is how to talk about URIs
> because in RDF they aren't first class citizens, they are simply ways to talk
> about resources. How can we associate the provenance properties that a
> bf:Identifier has with a URI without generating bad semantics? I think that a
> robust answer must use some kind of reification --- the way out of the "the
> first rule of identifier club is that you can't talk about identifiers" conundrum.
> 
> I'll use an example from Thomas and Rob to think about these 2 use cases:
> 
> On 7/17/14 12:17 PM, Robert Sanderson wrote:
>> Thomas Berger wrote:
>>> Now consider
>>> <http://example.org/persons/kcoyle> a bf:person;
>>>   bf:identifier [
>>>     bf:schema "VIAF";
>>>     bf:identifierValue "195531823";
>>>     bf:identifierValueURI <http://viaf.org/viaf/195531823>
>>>   ].
> 
> It seems that here the bf:identifierValueURI is a sleight of hand for
> bf:identifies (inverse of bf:identifier) and thus implies (though doesn't
> explicitly include):
> 
>> Or ... <http://example.org/persons/kcoyle> owl:sameAs
>> <http://viaf.org/viaf/195531823> .
> 
> The bf:identifierValueURI form is both somewhat circular and hard to compute on
> without bf-specific understanding. It thus doesn't serve use case 1 well.

The intention was /not/ to imply owl:sameAs. Equivalence is asserted only
within the context of the identifier scheme given.

The example I tried to supply was to connect an FRBR-aware manifestation record
with some "naive" description mixing work, manifestation and item level
properties (as one would probably find in a museum database):
Operating with owl:sameAs would be extremely problematic since the entities
within the two datasets never match. ISBNs as identifiers however still work,
since restriction to those aspects spanned up by "ISBN semantics" is
implicit.

I still have no opinion whether IRIs or stringifications of IRIs are
better suited for use case 1. But we have to keep in mind that for
some identifiers (e.g. ORCID, NBN-URNs for born-digital materials) an
"URI form" is the most official and preferred form of citing and
bf:Identifiers have to cope with them too, not only with plain old numbers.

As for use case 2 I see much similarity with the classification discussion
which took place today: The graph for an identifier (seen as an abstract
"concept" like places in classification systems) should contain a
reference URI for the scheme/system it is originating from and one or
more "manifestations" / labels one may encounter - strings or URIs.
Both together determine exactly this identifier (I'm avoiding to speak about
identifying the identifier) even in the case of anonymous nodes. This
kind of "indirect speech" also should prevent the conflation of identifier
URIs and resource URIs in cases where I add more provenance
information to a given bf:identifier.

There might however two use cases hidden in that scenario:
a) I might want to add statements to the identifier like 'another form
for the abstract isbn "x" is "978-y"'
b) Or I want to make a statement about one specific form: 'the form "978-y"
is utilized by the "z" dataset'

If a bf:Identifier is only allowed to carry exactly one value, then
there is no difference, but then I don't see a way to express fundamental
equivalences like that of ISBN-10 and ISBN-13 /within/ one bf:Identifier
graph (and expressing it with several graphs would open a gap between
them as wide as the gap between ISBN and OCLC number - completely unrelated
as identifiers and only evidence shows that they are always incurring at the
same resource)

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

iJwEAQECAAYFAlPQWrUACgkQYhMlmJ6W47PbYQQAjafs18Wjiz4h1FhqNKYZnNzC
xQJshW7ChwY7fKSopo993A06hXJcicgA2r1md5K9zFAGM65ZvwkHfXD3aqbja8LP
MCVuiLKveNrLxR6rDr9NEQ3+TxGs5Lex4PghSTIF6G1QyzMJtP+XR7ytJEytt0Cn
VsUsSqleFYFDH8LRynI=
=kiLr
-----END PGP SIGNATURE-----