Karen,

We would only use the ISBN in this property; the qualifying stuff belongs elsewhere.

Thanks to all of you who have weighed in.

Nate

Tom,

you bring up something that I now realize wasn't clear in Nate's message. Nate gave two examples:

bf:identifer  "9780394856308"^^http://example/org/isbn13
bf:isbn13 "9780394856308"

These appear to represent the ISBN only, not the entire 020 $a. So if the 020 $a were:

020 $a 9780394856308 (hardback)

what would be the output from the MARC record? Nate?

kc

Hello. Some thoughts about Nate’s modelling question having read the replies so far. I am more a cataloguer than a data modeller so please do correct my howlers and ignorance. I have assumed throughout that the ISBN (or any other bf:identifier) is not intended to directly identify the Instance but to be a property of the Instance.

 

a.       Treating ISBN as a data type seems to me to be stretching the definition of data type, at least as I understand it. I imagine the ISBN itself having the data type “string” (as it’s not a number, array, object or so on). The ISBN is so loosely typed in the way it is used (with and without dashes, with and without qualifiers, lower and upper case X, ten or 13 digits) that any data type would surely need a lot stricter definition. I have done a little playing with SPARQL and while I understand and applaud the fact that cataloguers should not have to be directly exposed to bibframe and that modelling the data well is more important than cataloguers being able to read it, I would much prefer something that SPARQL is actually able to handle and that is relatively robust and straightforward to interpret across datasets. Using a data type for what is really a property also seems dangerous to me: bf:title  "Hard times"^^http://example/org/uniform_title

b.      As Jörg (I think) pointed out, there are several possible versions of any ISBN and at least two are directly useful when looking at converting data from MARC21 to Bibframe (while appreciating that Bibframe’s ambitions are loftier than mere MARC replacement): the ISBN as given in a MARC record which is loose in the extreme (no dashes, all sorts of qualifiers: still v useful for ordering purposes and the like until someone comes up with something better) and the stripped down number (no dashes or qualifiers, X capitalized) which can be compared and matched easily across and within systems. I think bibo:isbn would do something like the latter(?) and, for the purposes of quick conversion, a bibframe:marc_isbn could be used to catch the rest?

c.       I agree that ISBN (and the LC number etc) are really textual properties rather than something that can be URIized, or rather it would be a huge amount of work to create a system where (avoiding using the ISBN in the URI itself as Richard Wallis suggests) http://alltheisbns.com/isbnforbook1234 could gather together all the various versions of an ISBN, for example. If one existed, then that would be great, but I would rather get our data out of MARC quickly and make it usable rather than worry about such a large bibliographic control project.

d.      I think that is would be preferable to have separate properties for each identifier (bf:isbn10, bf:isbn13, bf:lccn, and so on) for several reasons: (i) it seems a whole lot simpler and more elegant; (ii) I don’t think there would actually be so great a number of globally necessary identifiers that would  require such treatment. In due course, I imagine uris would replace local or consortial system numbers; (iii) bibo has gone down the same route as option 2: it seems wise to follow in others’ footsteps, or re-using what they have done, without a compelling reason not to.

e.      The qualifying data that currently gets lumped into 020$a fields in MARC should probably be addressed in some way, although I’m not sure how. If each Instance is equivalent to an ISBN then something like bf:binding and bibliographic data about volume numbers would suffice, but I imagine that would not be the case in practice. Both of my examples in (b) above skirt round the issue by including it as human-readable data in one case and killing it in the other, neither of which seem entirely satisfactory. Modelling an ISBN in a more complex manner also seems unattractive. There are certainly use cases in purchasing contexts.

 

I would go with something like option 2.

 

Many thanks,

 

Tom

 

---

 

Thomas Meehan

Head of Current Cataloguing

Library Services

University College London

Gower Street

London WC1E 6BT

 

[log in to unmask]

 

From: Bibliographic Framework Transition Initiative Forum [mailto:[log in to unmask]] On Behalf Of Trail, Nate
Sent: 01 August 2013 19:12
To: [log in to unmask]
Subject: Re: [BIBFRAME] Modeling Question

 

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]

-- 

Karen Coyle

[log in to unmask] http://kcoyle.net

ph: 1-510-540-7596

m: 1-510-435-8234

skype: kcoylenet