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