-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Interesting to see Nate's inconsistency in formulating the question:
>>> 2) specific property:****
>>>
>>> bf:isbn13 "9780394856308"*
>>> ***
>>>
>>> ** **
>>>
>>> where 'bf:isbn' is a subproperty of 'bf:identifier'.****
Thus the specific property could well be
bf:isbn "9780394856308"^^http://example/org/isbn13
distinguishing the kind of identifier used from its manifestation in
a certain notational system? (And please: The *official* form of
ISBNs as stated by the ISBN agency contains dashes and one has to
respect this, even if publisher tradition in certain countries puts
blanks between the groups and MARC 020 codes neither of them)
As for the use of URIs: We have to admit that /identifiers/ exist
outside of the web and most of them do not have a canonical form
as (HTTP)URIs. ISNI, ISIL and LCCN immediately come to my mind.
And even when canonical URIs are introduced for identifiers
completely under our control (e.g. LC could go forward and make
http://id.loc.gov/authorities/names/n79021400 something official)
other forms of those identifiers like "n 7921400" would not
vanish immediately or even retrospectively. Thus very often we
have several, official or at least "established" conventions
for those identifiers and an URI is only one of them. Converting
between those is an insideous and often by no means trivial task
(you must know the LC documentation to insert/remove spaces and zeroes
into their appropriate places in an LCCN and the country and
prefix tables of the ISBN agency are absolutely neccessary to
insert delimiters into ISBNs, and of course you'll have to know
the rules to convert between ISBN-10 and ISBN-13).
I think more important than normalizing those identifiers is the
task of identifying them: When you have a bunch of uniform
uris like urn:isbn:9780394856308 , urn:isbn:0521294061 and so
on, I tend to see the /identifiers/ 9780394856308 and 0521294061
as a parametrization of the resulting data set (those ressources
identified by the respective URIs). What is missing in the picture
(I think the VoID spec has some thoughts on it) is naming the sets
and data sets involved:
- - The set of all (abstract) ISBNs you can use for this (the domain
of the parametrization seen as a Map from Identifier space to
URI space)
- - the target data set of all objects identifyable by ISBN uris
(with "abstract" I mean that "0-394-85630-9" and "0 394 85630 9"
and "0394856309" or those digits spoken or sung in any language
and tune or bar-coded or qr-coded or calligraphed in any technical
format all /are/ (=mean) the absolutely same ISBN-10, they are
just notational variants of it)
Unfortunately no official URIs exist for those sets, usually one
helps oneself by using truncated URIs of instances. The turtle
notation:
PREFIX isbn: <urn:isbn>
isbn:9780394856308 a <http://purl.org/ontology/bibo/Book>
unfortunately blurs the distinction between identifiers and URIs:
There is missing a statement that "9780394856308" /is/ an
ISBN and that "isbn:9780394856308" (i.e. <urn:isbn:9780394856308>)
is /constructed/ from an ISBN is not expressible at all.
However one could choose <urn:isbn> as URI for either the data set
of all legal urn:isbn: URIs or the set of all legal (or almost legal?)
ISBN identifiers (but probably not both).
A statement like
isbn:9780394856308 bf:isbn "9780394856308"
or
isbn:9780394856308 bf:isbn10 "0-394-85630-9"
or
isbn:9780394856308 bf:isbn10 "0394856309"
closes the gap, giving us < http://bibframe.org/vocab/isbn10 > as
URI for the domain of all (abstract) ISBN-10s (Joerg will correct me:
my "parametrization" is the inverse of the bf:isbn10 /property/).
I think this is an important achievement (or does it imply an undesirable
identification of a property with a class?).
[Since in the future not all ISBN-13's will be expressible as ISBN-10's
there is nothing wrong in distinguishing between bf:isbn10 and bf:isbn13.]
However we are not in a position to declare either "0-394-85630-9"
or "0394856309" as being wrong or illegal (as usual we could declare
this for "our" community but would immediately loose interoperability
with any community adhering to different conventions) it would be a nice
option to have a /bunch/ of datatypes suitable for the bf:isbn10 property:
I imagine
http://example/org/isbn10
as the most loose (9 digits with check digit, optionally interspersed
with dashes or blanks, /no/ validity constraint on the correctness of
the check digit)
http://example/org/isbn10-condensed
just the digits
http://example/org/isbn10-official
digits and the correct number of dashes
http://example/org/isbn10-valid
checksum is alright
and so on.
viele Gruesse
Thomas Berger
Am 01.08.2013 21:20, schrieb [log in to unmask]:
> It depends on whether Web Ontology Language (OWL) methods should be applied
> to Bibframe for resolution of works and instances, or if ISBN identifiers
> should be moved away from the Bibframe scope to get handled in programming
> languages.
>
> Option 1) is applying datatypes to ISBN. The essentials for RDF datatypes
> are described in http://www.w3.org/TR/rdf-concepts/#section-Datatypes
> The challenge with option 1) is that ISBNs must conform to the RDF rule
> that there must be a lexical space, a value space, and a lexical-to-value
> mapping. In my bibliographic applications I store each ISBN three times: an
> original form (the lexical value from a catalog source, including incorrect
> ISBNs), a value form (without hyphens and correct checksum and each ISBN-10
> mapped to ISBN-13), and the alternative value (ISBN-10, if existing, with
> the ISBN-10 checksum, for matching all kinds of ISBN queries). This shows
> there is a normal form of an ISBN, but it can be augmented with variants
> which are also valid, which adds some complexity to parse and represent
> ISBNs like we programmers do with datatypes in programming languages. It is
> possible to implement, but not easy to explain to the hasty programmers or
> sceptical users out there.
>
> Option 2) is useful for resolving inverse functional properties in OWL,
> that is, if there is a property bf:isbn with the same literals asserted to
> two different subjects, the assumption can hold that the two subjects are
> equal under the presumption only one bf:isbn property can be asserted. This
> reminds me of the bf:Instance discussion that bf:isbn might identify a
> bf:Instance. Such ISBN literals can be arbitrary strings. It does not
> matter if they are ISBN-10, ISBN-13, with or without hyphens, correct or
> incorrect variants. It should not be expected that OWL resolution can
> normalize all forms of an ISBN intrinsically. The normalization would be an
> extra step in the preparation of Bibframe data, like we are used to it in
> the world of MARC today.
>
> Jörg
>
>
>
>
>
>
> On Thu, Aug 1, 2013 at 8:17 PM, Robert Sanderson <[log in to unmask]>wrote:
>
>>
>> I guess that actually using RDF is out of the question and having a URI
>> for identifiers?
>>
>> See: http://www.ietf.org/rfc/rfc3187.txt
>>
>> Rob
>>
>>
>> On Thu, Aug 1, 2013 at 12:12 PM, Trail, Nate <[log in to unmask]> wrote:
>>
>>> All,****
>>>
>>> ** **
>>>
>>> We're thinking about modeling identifiers (and other properties?) in two
>>> ways:****
>>>
>>> ** **
>>>
>>> 1) generic property with a more specific data type:****
>>>
>>> ** **
>>>
>>> bf:identifer "9780394856308"^^http://example/org/isbn13*
>>> ***
>>>
>>> ** **
>>>
>>> or****
>>>
>>> ** **
>>>
>>> 2) specific property:****
>>>
>>> bf:isbn13 "9780394856308"*
>>> ***
>>>
>>> ** **
>>>
>>> where 'bf:isbn' is a subproperty of 'bf:identifier'.****
>>>
>>> ** **
>>>
>>> How does the community feel about these two options, and why?****
>>>
>>> ** **
>>>
>>> Thanks,****
>>>
>>> ** **
>>>
>>> Nate****
>>>
>>> ** **
>>>
>>> -------------------------------------------****
>>>
>>> Nate Trail****
>>>
>>> -------------------------------------------****
>>>
>>> LS/TECH/NDMSO****
>>>
>>> Library of Congress****
>>>
>>> 202-707-2193****
>>>
>>> [log in to unmask]****
>>>
>>
>>
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iJwEAQECAAYFAlH65zkACgkQYhMlmJ6W47M2PQQAlXkiRsFFK+Bi8uDXK1l71HRN
kd2YkAnZrKQ8/V9swc/HxFNQiMaYIVUo3R/NQog4DylhdCNJVS+feiDK1hqYiLqo
SEYFAM/fTzQKceakSxnexY9on1elB0sNDMs/SSZew4MVtmqv1Wv8PniQ7p5gO+Kv
GJvfmQFvWQYuFzekyiE=
=qpgS
-----END PGP SIGNATURE-----
|
