Re: [RDA-L] Browse and search BNB open data
02.08.2011 18:34, J. McRee Elrod: http://www.allegro-c.de/db/a30/bl.htm Am I correct that there is no MARC display available? OK, for what it's worth and for good measure, I've added that in; no big deal since we've got what it takes. Now, MARC appears directly underneath the regular display. But only as complete and as correct as the stuff that was released. The format made available by BL is an XML schema of their own design, documented here: http://www.bl.uk/bibliographic/datafree.html (under Data model draft schema) A sample XML record: rdf:Description dcterms:titleThe elves and the emperor/dcterms:title dcterms:creator rdf:Description rdfs:labelRobinson, Hilary, 1962-/rdfs:label /rdf:Description /dcterms:creator dcterms:contributor rdf:Description rdfs:labelSanfilippo, Simona./rdfs:label /rdf:Description /dcterms:contributor dcterms:type rdf:Description rdfs:labeltext/rdfs:label /rdf:Description /dcterms:type dcterms:type rdf:Description rdfs:labelmonographic/rdfs:label /rdf:Description /dcterms:type isbd:P1016 rdf:Description rdfs:labelLondon/rdfs:label /rdf:Description /isbd:P1016 dcterms:publisher rdf:Description rdfs:labelWayland/rdfs:label /rdf:Description /dcterms:publisher dcterms:issued2009/dcterms:issued dcterms:language rdf:Description rdf:value rdf:datatype=http://purl.org/dc/terms/ISO639-2;eng/rdf:value /rdf:Description /dcterms:language dcterms:extent rdf:Description rdfs:label31 p/rdfs:label /rdf:Description /dcterms:extent dcterms:descriptionOriginally published: 2008./dcterms:description dcterms:subject skos:Concept skos:notation rdf:datatype=ddc:Notation428.6/skos:notation skos:inScheme rdf:resource=http://dewey.info/scheme/e22; / /skos:Concept /dcterms:subject dcterms:isPartOf rdf:Description rdfs:labelFairytale jumbles/rdfs:label /rdf:Description /dcterms:isPartOf dcterms:isPartOf rdf:Description rdfs:labelStart reading. Purple band 8/rdfs:label /rdf:Description /dcterms:isPartOf dcterms:identifier(Uk)015346892/dcterms:identifier dcterms:identifierGBA979108/dcterms:identifier bibo:isbn9780750255233/bibo:isbn bibo:isbn0750255234/bibo:isbn dcterms:identifierURN:ISBN:9780750255233/dcterms:identifier dcterms:identifierURN:ISBN:0750255234/dcterms:identifier /rdf:Description which translates like this: =LDR 01234cam a22002771i 45e0 =001 015346892 =007 ta =008 \\991231s2009n\\\eng\d =020 \\$a9780750255233 =040 $ea =082 00$a428.6 =100 1\$aRobinson, Hilary (1962-) =245 04$aThe elves and the emperor /$cHilary Robinson =260 \\$aLondon :$bWayland,$c2009 =300 \\$a31 p =440 \0$aFairytale jumbles =440 \0$aStart reading. Purple band 8 =500 \\$aOriginally published: 2008. =700 12$aSanfilippo, Simona B.E.
Re: [RDA-L] Browse and search BNB open data
On 03/08/2011 08:34, Bernhard Eversberg wrote: snip 02.08.2011 18:34, J. McRee Elrod: http://www.allegro-c.de/db/a30/bl.htm Am I correct that there is no MARC display available? OK, for what it's worth and for good measure, I've added that in; no big deal since we've got what it takes. Now, MARC appears directly underneath the regular display. But only as complete and as correct as the stuff that was released. The format made available by BL is an XML schema of their own design, documented here: http://www.bl.uk/bibliographic/datafree.html (under Data model draft schema) /snip This is interesting. From the table http://www.bl.uk/bibliographic/pdfs/marctordfxmlmappingsv0-3-2.pdf, we see how some of the semantics of the MARC format are lost in the conversion. As we evolve away from the MARC format, I am sure the direction will be toward simplification, so it seems valuable to discuss what could be eliminated from MARC with the fewest consequences. From a very quick review of that table, I see the 534 being translated to dcterms:description, losing some handy subfields, and all of the subfields in the 100/700 fields mapping to dcterms:creator. Also, all of the subfields in the 6xx fields are being placed into dcterms:subject, and there is a loss of the subfield description avxyz. I need to emphasize that this is discussing losing the specific subfield *coding*, NOT losing the information, e.g. 100 0_*|a *Benedict*|b *XVI,*|c *Pope,*|d *1927- as opposed to *dcterms:creator*Benedict**XVI,**Pope,**1927-*/dcterms:creator* In practical terms for all the various metadata communities, where precisely is the loss here? While there is an undoubted loss in semantics, with the future evolution of MARC format, we can ask: do such losses have any practical consequences? Although I think many subfields (although not the information) could disappear without any essential loss, some will have important consequences to different communities. For instance, we see in the mapping the complete elimination of 245$c, which would obviously have important consequences for *librarians* (i.e. necessary for determination of a copy), although the loss of 245$c would be much less dire for the users. Loss of subfields with some of the most consequences would seem to be the subfields in the 6xx fields, since those semantics *could* lead to novel computer manipulation, sorting by chronology, geographic, and all kinds of other ways. Also, the distinctions of: 650$aHistory$xBibliography 650$aHistory$vBibliography 650$aBibliography$xHistory would be lost. Compare this to losing the subfields in the 1xx/7xx, where the consequences would appear to be much fewer. Yet, compare this to what others want: even more semantics, for example, to encode 300$a even further to specify pages or leaves or whatever. e.g. 300 a pages 245 /pages leaves 56 /leaves /a /300 etc. There are definite advantages with this level of coding but on the negative side, it is more work, prone to many more errors, and is more difficult to train new people, especially as there will be the push to simplify. I think these questions will begin to be asked (finally!), and answered too. This project from the British Library may be a great catalyst for the discussion. -- James Weinheimer weinheimer.ji...@gmail.com First Thus: http://catalogingmatters.blogspot.com/ Cooperative Cataloging Rules: http://sites.google.com/site/opencatalogingrules/
Re: [RDA-L] Browse and search BNB open data
Am 03.08.2011 10:55, schrieb James Weinheimer: There are definite advantages with this level of coding but on the negative side, it is more work, prone to many more errors, and is more difficult to train new people, especially as there will be the push to simplify. I think these questions will begin to be asked (finally!), and answered too. This project from the British Library may be a great catalyst for the discussion. The BL has teamed up with Talis to develop and improve their open data activities. Here's more about that, together with a nice diagram any cataloger might love to mount on their office wall: http://consulting.talis.com/2011/07/british-library-data-model-overview/ I understand that the current release is only a first step, and together with Talis they will produce an improved version in the near future. B.Eversberg
Re: [RDA-L] Browse and search BNB open data
Bernard and all, In order to clarify the current situation, The British Library would like to take this opportunity to outline the range of free/open BNB options and encourage anyone seeking details to check http://www.bl.uk/bibliographic/datafree.html for further information. We would like to emphasise the experimental nature of this work and the likelihood that datasets we make available will be subject to change over time. As a result, we would recommend that those wishing to use the most up to date version of the BNB dataset obtain it directly from the BL. Older versions available from other sites have now been superseded and we will be contacting organisations we identify mounting these to offer updated versions. The current BNB options are: 1) BNB as linked data (the latest free data release, in association with Talis) - Available under a CC0 license using: SPARQL, Describe and Search endpoints. This dataset has been updated from an initial preview version of around 400,000 records to cover over 2.6 million monographs (80,249,538 triples) ; we hope to also offer a dump of the file via FTP shortly using the new data model (available at http://www.bl.uk/bibliographic/pdfs/datamodelv1_01.pdf) and schema (available at: (http://www.bl.uk/bibliographic/pdfs/britishlibrarytermsv1-01.pdf) 2) BNB in basic RDF/XML via FTP (the dataset currently under discussion) - Available under a CC0 license to individual researchers or organisations not requiring MARC21 data but wishing to data mine, mash up or otherwise interrogate the data set in bulk. An updated version is currently being produced which will be available via FTP directly from the BL - please contact metad...@bl.uk for access details. 3) BNB Z39.50 MARC21 Access - A free registration based service for non-commercial use under terms outlined on the British Library free data web page at: http://www.bl.uk/bibliographic/datafree.html If you have any queries about any of the BNB data offerings, please contact us at metad...@bl.uk Thank you Best regards Corine Corine Deliot on behalf of Metadata Services, The British Library. email: metad...@bl.uk From: Resource Description and Access / Resource Description and Access [mailto:RDA-L@LISTSERV.LAC-BAC.GC.CA] On Behalf Of Bernhard Eversberg Sent: 03 August 2011 10:14 To: RDA-L@LISTSERV.LAC-BAC.GC.CA Subject: Re: [RDA-L] Browse and search BNB open data Am 03.08.2011 10:55, schrieb James Weinheimer: There are definite advantages with this level of coding but on the negative side, it is more work, prone to many more errors, and is more difficult to train new people, especially as there will be the push to simplify. I think these questions will begin to be asked (finally!), and answered too. This project from the British Library may be a great catalyst for the discussion. The BL has teamed up with Talis to develop and improve their open data activities. Here's more about that, together with a nice diagram any cataloger might love to mount on their office wall: http://consulting.talis.com/2011/07/british-library-data-model-overview/ I understand that the current release is only a first step, and together with Talis they will produce an improved version in the near future. B.Eversberg
Re: [RDA-L] Browse and search BNB open data
In article 4e38ebe3.5090...@biblio.tu-bs.de, you wrote:
OK, for what it's worth and for good measure, I've added that in;
no big deal since we've got what it takes.
Bless your sweet heart.
Did you notice the not for commercial purposes in the BL posting? We
are not even going to ask. No matter how much we give back, as
outsourcer we are made to feel dirty.
How anyone comparing the XML and MARC versions could prefer the XML is
beyond me. We find it simple to crosswalk from MARC to XML for anyone
who wants it, but not back again.
Mac
__ __ J. McRee (Mac) Elrod (m...@slc.bc.ca)
{__ | / Special Libraries Cataloguing HTTP://www.slc.bc.ca/
___} |__ \__
Re: [RDA-L] Browse and search BNB open data
Quoting James Weinheimer weinheimer.ji...@gmail.com: While there is an undoubted loss in semantics, with the future evolution of MARC format, we can ask: do such losses have any practical consequences? Although I think many subfields (although not the information) could disappear without any essential loss, some will have important consequences to different communities. Jim, this is much of the motivation for the work that I have been doing to try to identify the actual elements of MARC21 -- elements in the semantic sense, trying to ignore the MARC21 structure (which results in much repetition, etc.) A report on my study is available in the recent Code4Lib journal: http://journal.code4lib.org/articles/5468 One of the difficulties of deciding what we do and do not want to keep in MARC, or what we want to move over to the RDA environment, is that we have no dictionary of everything that MARC covers. For example, what standard identifiers are available in MARC? They are scattered all over the format, so it's hard to know. What about things like language and date? Those appear in different fields with somewhat different meanings. My assumption is that a complete inventory of MARC elements is essential for any move away from MARC. Unfortunately, I have gotten now to the 1xx-8xx fields (the study so far is 00x and 0xx, that's already pretty complex!) and may not have the energy to complete the study on my own. However, what I have done so far at least sets down some possible principles to follow. I'm doing it all on the futurelib wiki so my process is as transparent as I can make it: http://futurelib.pbworks.com/w/page/29114548/MARC%20elements kc -- Karen Coyle kco...@kcoyle.net http://kcoyle.net ph: 1-510-540-7596 m: 1-510-435-8234 skype: kcoylenet
Re: [RDA-L] Article on RDA implementation
http://www.libraryjournal.com/lj/home/891482-264/cataloging_community_galvanized_as_u.s..csp
It says:
However, the JSC will no longer update AACR2. So continuing to use these
rules does not remain a viable long term option.
This does not preclude others doing so. The most widely used rules in
the world are various translations of Concise AACR2.
If the conditions set by the US national libraries are not met, and
RDA is not implemented, JSC might have to reconsider its decision not
to update AACR2.
Thanks to Allen Mullen for posting this URL to Autocat.
__ __ J. McRee (Mac) Elrod (m...@slc.bc.ca)
{__ | / Special Libraries Cataloguing HTTP://www.slc.bc.ca/
___} |__ \__
