 |
 |
> Anything that will remodel MARC to (decent) RDF is going be: > > - Non-trivial to install > - Non-trivial to use > - Slow > - Require massive amounts of memory/disk space > > Choose any two. -- I'll second this. > Frankly, I don't see how you can generate RDF that anybody would want to > use from XSLT: where would your URIs come from? What, exactly, are you > modeling? -- Our experience getting to good, URI rich RDF has been basically a two-step process. First there is the "raw" conversion, which certainly results in verbose blank-node-rich RDF, but we follow that pass with a second one during which blank nodes are replaced with URIs. This has most certainly been the case with BIBFRAME because X number of MARC records may represent varying manifestations of a single work. We don't want X number of instances (manifestations basically) referencing X number of works in the end, but X number of instances referencing 1 work (all other things being equal). We consolidate - for the lack of a better word - X number of works created in the first pass into 1 work (identified by an HTTP URI) and then we make sure X number of instances point to that one work, removing all the duplicate blank-node-identified resources created during the first pass. Granted this consolidation scenario is not scalable without a fairly robust backend solution, but the process at bibframe.org (the code on github) nevertheless does the type of consolidation described above in memory with small MARC collections. Yours, Kevin On 12/05/2013 08:55 AM, Ross Singer wrote: > Eric, I'm having a hard time figuring out exactly what you're hoping to get. > > Going from MARC to RDF was my great white whale for years while Talis' main > business interests involved both of those (although not archival > collections). Anything that will remodel MARC to (decent) RDF is going be: > > - Non-trivial to install > - Non-trivial to use > - Slow > - Require massive amounts of memory/disk space > > Choose any two. -- > > Frankly, I don't see how you can generate RDF that anybody would want to > use from XSLT: where would your URIs come from? What, exactly, are you > modeling? > > I guess, to me, it would be a lot more helpful for you to take an archival > MARC record, and, by hand, build an RDF graph from it, then figure out your > mappings. I just don't see any way to make it "easy-to-use", at least, not > until you have an agreed upon model to map to. > > -Ross. > > > On Thu, Dec 5, 2013 at 3:07 AM, Christian Pietsch < > [log in to unmask]> wrote: > >> Hi Eric, >> >> you seem to have missed the Catmandu tutorial at SWIB13. Luckily there >> is a basic tutorial and a demo online: http://librecat.org/ >> >> The demo happens to be about transforming MARC to RDF using the >> Catmandu Perl framework. It gives you full flexibility by separating >> the importer from the exporter and providing a domain specific >> language for “fixing” the data in between. Catmandu also has easy >> to use wrappers for popular search engines and databases (both SQL and >> NoSQL), making it a complete ETL (extract, transform, load) toolkit. >> >> Disclosure: I am a Catmandu contributor. It's free and open source >> software. >> >> Cheers, >> Christian >> >> >> On Wed, Dec 04, 2013 at 09:59:46PM -0500, Eric Lease Morgan wrote: >>> Converting MARC to RDF has been more problematic. There are various >>> tools enabling me to convert my original MARC into MARCXML and/or >>> MODS. After that I can reportably use a few tools to convert to RDF: >>> >>> * MARC21slim2RDFDC.xsl [3] - functions, but even for >>> my tastes the resulting RDF is too vanilla. [4] >>> >>> * modsrdf.xsl [5] - optimal, but when I use my >>> transformation engine (Saxon), I do not get XML >>> but rather plain text >>> >>> * BIBFRAME Tools [6] - sports nice ontologies, but >>> the online tools won’t scale for large operations >> >> -- >> Christian Pietsch · http://www.ub.uni-bielefeld.de/~cpietsch/ >> LibTec · Library Technology and Knowledge Management >> Bielefeld University Library, Bielefeld, Germany >>