> 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 <
chr.pietsch+web4...@googlemail.com> 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
