LISTSERV mailing list manager LISTSERV 16.0

Help for BIBFRAME Archives


BIBFRAME Archives

BIBFRAME Archives


BIBFRAME@LISTSERV.LOC.GOV


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Proportional Font

LISTSERV Archives

LISTSERV Archives

BIBFRAME Home

BIBFRAME Home

BIBFRAME  August 2013

BIBFRAME August 2013

Subject:

Re: Modeling Question

From:

Thomas Berger <[log in to unmask]>

Reply-To:

[log in to unmask]

Date:

Fri, 2 Aug 2013 00:54:49 +0200

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (240 lines)

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

Top of Message | Previous Page | Permalink

Advanced Options


Options

Log In

Log In

Get Password

Get Password


Search Archives

Search Archives


Subscribe or Unsubscribe

Subscribe or Unsubscribe


Archives

November 2020
October 2020
September 2020
August 2020
July 2020
June 2020
May 2020
April 2020
March 2020
February 2020
January 2020
December 2019
November 2019
October 2019
September 2019
August 2019
July 2019
June 2019
May 2019
April 2019
March 2019
February 2019
January 2019
December 2018
November 2018
October 2018
September 2018
August 2018
July 2018
June 2018
May 2018
April 2018
March 2018
February 2018
January 2018
December 2017
November 2017
October 2017
September 2017
August 2017
July 2017
June 2017
May 2017
April 2017
March 2017
February 2017
January 2017
December 2016
November 2016
October 2016
September 2016
August 2016
July 2016
June 2016
May 2016
April 2016
March 2016
February 2016
January 2016
December 2015
November 2015
October 2015
September 2015
August 2015
July 2015
June 2015
May 2015
April 2015
March 2015
February 2015
January 2015
December 2014
November 2014
October 2014
September 2014
August 2014
July 2014
June 2014
May 2014
April 2014
March 2014
February 2014
January 2014
December 2013
November 2013
October 2013
September 2013
August 2013
July 2013
June 2013
May 2013
April 2013
March 2013
February 2013
January 2013
December 2012
November 2012
October 2012
September 2012
August 2012
July 2012
June 2012
May 2012
April 2012
March 2012
February 2012
January 2012
December 2011
November 2011
October 2011
September 2011
July 2011
June 2011

ATOM RSS1 RSS2



LISTSERV.LOC.GOV

CataList Email List Search Powered by the LISTSERV Email List Manager