 |
 |
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 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) > 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 > <http://bibotools.googlecode.com/svn/bibo-ontology/trunk/doc/dataproperties/identifier___431915395.html> > 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] <mailto:[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