+1
Thanks,
Shlomo
Experience the all-new, singing and dancing interactive Primo brochure
-----Original Message-----
From: Bibliographic Framework Transition Initiative Forum [mailto:[log in to unmask]] On Behalf Of Thomas Berger
Sent: Thursday, July 17, 2014 13:44
To: [log in to unmask]
Subject: Re: [BIBFRAME] BibFrame and Linked Data: Identifiers
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
The message quoted below was sent to my private adress rather than the list, I really hope no offense is taken when I feed it back to the list, especially since my answer also tries to address Ray Denenberg's remark about objections to the bf:uri property.
Am 17.07.2014 00:01, schrieb Karen Coyle:
>
> On 7/16/14, 1:45 PM, Thomas Berger wrote:
>> Listing strings and URIs (perhaps not as identifierValue but as an
>> hypothetic identifierURI) within the same container is not
>> contradictory on a formal level, I think.
> The problem there was precisely addressed in:
>
> http://listserv.loc.gov/cgi-bin/wa?A2=ind1407&L=bibframe&T=0&P=8029
>
> As Rob says there, and Ray and Kevin concur, it is a problem if the
> same URI is used to represent more than one thing. I would expect
> reasoners to choke on this as an inconsistency.
>
> It is NOT a problem to have multiple URIs for the SAME thing, and,
> sure, you can say that they are the same identifier in a different
> form. But you should not expect to use a URI both as an object of the property bf:identifier and as a RWO.
Sure. But Rob's (absolutely valid) point are the inconsistencies arising from resource URIs we want to distinguish as "identifiers" simultaneously used as resource URI for the bf:Identifier as such. Making statements about some URIs (as URIs as in contrast to the resources they represent) would constitute a more subtle form of the same(?) fallacy and is likewise absolutely not admissible.
My point of view however would be to simply dispense n URIs into m bf:Identifier containers and keep them striclty in object position there...
We could write
<http://www.example.org/xyz>
a bf:Instance;
... our description ... ;
owl:sameAs <urn:isbn:1-2-3>, <info:isbn/1234> .
but this really are just two odd URIs we additionally provide. To conclude any connection with the ISBN system is a delusion arising from the fact that we humans cannot resist interpreting URIs and charging them with meaning we strive to detect in their string representation (Imagine this was an HTML formatted mail and I would provide a QR code instead of a string between the angle brackets.)
On the other hand a graph
<http://www.example.org/xyz>
a bf:Instance;
... our description ... ;
bf:identifier [
a bf:Identifier,
bf:identifierScheme "ISBN",
bf:identifierValue "978-1-2-3",
bf:identifierValueURI <urn:isbn:978-1-2-3>, <info:isbn/123> .
] .
would assert that within the semantic context of "ISBN"
the two URIs provided
a) "make sense" (meet a certain consensus about admissible
denominations) [or is this already a fallacious statement
/about/ the URIs as such?]
and b) their corresponding resources are equivalent to
our resource
and therefore c) their corresponding resources are
the same.
This still does not open the URIs given to analysis or algorithmic transformations but at least establishes their "ISBN" context.
Alternatively we (not RDF) could transform the URIs into literals and state
<http://www.example.org/xyz>
a bf:Instance;
... our description ... ;
bf:identifier [
a bf:Identifier,
bf:identifierScheme "ISBN",
bf:identifierValue "978-1-2-3",
bf:identifierValueURIasString "urn:isbn:1-2-3", "info:isbn/1234" .
] .
These strings cannot be used as URIs any more but instead are open to inspection and algorithmic transformations.
Usage of identifierValueURIasString instead of a plain identifierValue would indicate that this literal could be turned into an URI by mechanisms outside of RDF. The distrinction would be simply for the convenience of the human reader...
Technically the basic thing we need our (real world, traditional) identifiers for is comparison (the real world tasks like "hunting down" I mentioned before are dealt with differently in semantic web contexts), but preferably according to the rules of the scheme they are taken from. For the three forms given in the example already we are stating their identity thus both versions serve our need. For other forms we may encounter in different graphs we could employ an hypothetical, "ISBN"-specfic canonicalization service of our choice - and perhaps it is more feasible to encode strings as parameters in URL construction for that service than URIs.
As mentioned the string "ISBN" as value for bf:identifierScheme is not a favorable way of fixating the scheme. Bibframe also provides the "isbn" subproperty with isbn10 and isbn13 sub-subproperties
The official example
<http://id.loc.gov/resources/bibs/17082740> a bf:Work ;
bf:hasInstance [ a bf:Instance ;
bf:isbn13 <http://isbn.example.org/9780738609089> ] .
does not tell us about the ISBN as a real world identifier, we'll have to resort to <http://isbn.example.org/9780738609089>
(read: <http://my.volatile.private.isbn.identifier.store.example.org>)
first and may see there:
<http://isbn.example.org/9780738609089> a bf:Identifier ;
bf:identifierScheme "ISBN";
bf:identifierValue "978-0-7386-0908-9".
Or combined and restated the preferred way with an anonymous node:
<http://id.loc.gov/resources/bibs/17082740> a bf:Work ;
bf:hasInstance [ a bf:Instance ;
bf:isbn13 [ a bf:Identifier ;
bf:identifierScheme "ISBN";
bf:identifierValue "978-0-7386-0908-9".]
] .
By using the bf:isbn13 property our bf:Instance very strictly "knows" what kind of identifier it is referring to, however the identifier resource as such just vaguely performs an incantation of "ISBN": IMHO a grave deficiency of the current design.
Can this be remedied by also admitting the bibframe vocabulary for the subproperties as range for bf:identifierScheme instead of literals?
<http://isbn.example.org/9780738609089> a bf:Identifier ;
bf:identifierScheme bf:isbn;
bf:identifierValue "978-0-7386-0908-9".
yielding
<http://id.loc.gov/resources/bibs/17082740> a bf:Work ;
bf:hasInstance [ a bf:Instance ;
bf:isbn13 [ a bf:Identifier ;
bf:identifierScheme bf:isbn;
bf:identifierValue "978-0-7386-0908-9".]
] .
Or maybe the other way round:
<http://id.loc.gov/resources/bibs/17082740> a bf:Work ;
bf:hasInstance [ a bf:Instance ;
bf:isbn [ a bf:Identifier ;
bf:identifierScheme bf:isbn13;
bf:identifierValue "978-0-7386-0908-9".]
] .
or more generic
<http://id.loc.gov/resources/bibs/17082740> a bf:Work ;
bf:hasInstance [ a bf:Instance ;
bf:identifier [ a bf:Identifier ;
bf:identifierScheme bf:isbn13;
bf:identifierValue "978-0-7386-0908-9".]
] .
However ISBN-10/ISBN-13 issues are peculiar to the ISBN system requiring a more thorough discussion I do not deem appropriate in this thread.
viele Gruesse
Thomas Berger
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iJwEAQECAAYFAlPHqOAACgkQYhMlmJ6W47MuAQP/bVsrm24z3x1nw/CY+qGpT6xN
2LXbDw/R3cl/AYRTy9tBDEoPr62rR51kWVCclPATeszmV+ViAnf9+me7WZdLwD9o
+t/Z4xwpnAKgsV69e6I7Scflabj/P+mu6iYdj12ld2mK/FQaaFK3RTAwgvmACcku
s5kCgC/6hFJsCmlZ4F4=
=m9X3
-----END PGP SIGNATURE-----
|