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?


On 8/8/13 4:19 AM, Meehan, Thomas wrote:
> 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) 
> 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
> -------------------------------------------
> Library of Congress
> 202-707-2193
> [log in to unmask] <mailto:[log in to unmask]>

Karen Coyle
[log in to unmask]
ph: 1-510-540-7596
m: 1-510-435-8234
skype: kcoylenet