A few of the code4lib talk proposals mention projects that have or
will transform MARC records into RDF. If any of you have documentation
and/or examples of this, I would be very interested to see them, even
if they are "under construction."
Thanks,
kc
--
Karen Coyle
kco...@kcoyle.net http
I was at a one-day conference hosted by the British Library a few
months ago, on the use of Linked Data in libraries. There were about
50 people there in total. It became apparent that between us we
represented AT LAST ten separate projects (or parts of bigger project)
for converting MARC data in
It would be great to start collecting transforms together - just a quick brain
dump of some I'm aware of
MARC21 transformations
Cambridge University Library - http://data.lib.cam.ac.uk - transformation made
available (in code) from same site
Open University - http://data.open.ac.uk - specific tr
You may know about this one already, but the BL exposed the British
National Bibliography as RDF last summer. The project has a page[1] with
a good amount of info--the data model[2] might be a good place to start.
-Jon
1. http://www.bl.uk/bibliographic/datafree.html
2. http://www.bl.uk/bibliogr
Mike, that's what I suspected is going on. It might be good to mine
those efforts, contrast and compare. Maybe not the details, but the
general models.
kc
Quoting Mike Taylor :
I was at a one-day conference hosted by the British Library a few
months ago, on the use of Linked Data in librar
Wow. Thank you, Owen! As a way not to lose these, I have done a crude
page on the futurelib wiki with the contents of your mail, and promise
to clean it up at some not too distant date:
http://futurelib.pbworks.com/w/page/48408645/MARC%20in%20RDF
When/if I get the time, I will try to dig in
Owen-
Another strategy for capturing MARC data in RDF is to convert it to MODS (we do
this using the LoC MARC to MODS stylesheet:
http://www.loc.gov/standards/marcxml/xslt/MARC21slim2MODS.xsl). From there,
it's pretty easy to incorporate into RDF. There are some issues to be aware
of, such a
Hi Esme - thanks for this. Do you have any documentation on which predicates
you've used and MODS->RDF transformation?
Owen
On 2 Dec 2011, at 16:07, Esme Cowles wrote:
> Owen-
>
> Another strategy for capturing MARC data in RDF is to convert it to MODS (we
> do this using the LoC MARC to MOD
Oh - and perhaps just/more importantly - how do you create URIs for you data
and how do you reconcile against other sources?
Owen
On 2 Dec 2011, at 16:07, Esme Cowles wrote:
> Owen-
>
> Another strategy for capturing MARC data in RDF is to convert it to MODS (we
> do this using the LoC MARC
Owen-
We assign ARKs[1] to our objects (and predicates for that matter). The issue
of reconciling against other sources hasn't come as much, since we have mostly
focused on our unique objects. But we have worked on that issue some. For
example, several years ago, I worked on the UCAI project
Esme, let me second Owen's enthusiasm for more detail if you can
supply it. I think we also need to start putting these efforts along a
"loss" continuum - MODS is already lossy vis-a-vis MARC, and my guess
is that some of the other MARC->RDF transforms don't include all of
the warts and wri
Owen mentioned the Talis (now Capita Libraries) model. If you'd like
more info on that, our tech lead put his slides from the Linked Data
in Libraries event online at:
http://www.slideshare.net/philjohn/linked-library-data-in-the-wild-8593328
They cover some of the work we've done, approaches tak
Thanks, Matt. The RDF here uses BIBO and DC, and is therefore
definitely lossy. I'm not saying that's a bad thing -- loss from MARC
may well be the only way to save library metadata. What I would be
interested in learning is how one decides WHAT to lose. I"m also
curious to know if any folk
On 12/5/2011 1:40 PM, Karen Coyle wrote:
This brings up another point that I haven't fully grokked yet: the use
of MARC kept library data "consistent" across the many thousands of
libraries that had MARC-based systems.
Well, only somewhat consistent, but, yeah.
What happens if we move to R
I looked into this a little more closely, and it turns out it's a little more
complicated than I remembered. We built support for transforming to MODS using
the MODS21slim2MODS.xsl stylesheet, but don't use that. Instead, we use custom
Java code to do the mapping.
I don't have a lot of public
Monday, December 05, 2011 10:57 AM
> To: CODE4LIB@LISTSERV.ND.EDU
> Subject: Re: [CODE4LIB] Models of MARC in RDF
>
> On 12/5/2011 1:40 PM, Karen Coyle wrote:
> >
> > This brings up another point that I haven't fully grokked yet: the use
> > of MARC kept librar
owles
Sent: Monday, December 05, 2011 11:22 AM
To: CODE4LIB@LISTSERV.ND.EDU
Subject: Re: [CODE4LIB] Models of MARC in RDF
I looked into this a little more closely, and it turns out it's a little more
complicated than I remembered. We built support for transforming to MODS using
the MODS21slim2MODS
om: Code for Libraries [mailto:CODE4LIB@LISTSERV.ND.EDU] On Behalf
Of Esme Cowles
Sent: Monday, December 05, 2011 11:22 AM
To: CODE4LIB@LISTSERV.ND.EDU
Subject: Re: [CODE4LIB] Models of MARC in RDF
I looked into this a little more closely, and it turns out it's a
little more complicated tha
, I remember running the entire Univ. of California union
> catalog on 35 megabytes, something that would now be considered a smallish
> email attachment.)
>
> kc
>
>>
>> D
>>
>> -Original Message-
>> From: Code for Libraries [mailto:CODE4LIB
I think the strength of adopting RDF is that it doesn't tie us to a single
vocab/schema. That isn't to say it isn't desirable for us to establish common
approaches, but that we need to think slightly differently about how this is
done - more application profiles than 'one true schema'.
This is
This is a *very* tangential rant, but it makes me mental when I hear
people say the "'disk space' is no longer an issue." While it's true that
the costs of disk drives continue to drop, my experience is that the cost
of managing storage and backups is rising almost exponentially as
libraries conti
Well said Will,
Mark
- Original Message -
> This is a *very* tangential rant, but it makes me mental when I hear
> people say the "'disk space' is no longer an issue." While it's true
> that
> the costs of disk drives continue to drop, my experience is that the
> cost
> of managing storag
December 06, 2011 10:51 AM
To: CODE4LIB@LISTSERV.ND.EDU
Subject: Re: [CODE4LIB] Models of MARC in RDF
Well said Will,
Mark
- Original Message -
> This is a *very* tangential rant, but it makes me mental when I hear
> people say the "'disk space' is no longer an issue."
[mailto:CODE4LIB@LISTSERV.ND.EDU] On Behalf Of Owen
Stephens
Sent: Tuesday, December 06, 2011 8:06 AM
To: CODE4LIB@LISTSERV.ND.EDU
Subject: Re: [CODE4LIB] Models of MARC in RDF
I'd suggest that rather than shove it in a triple it might be better to point
at alternative representations, incl
stbrook.
Gabriela
-Original Message-
From: Code for Libraries [mailto:CODE4LIB@LISTSERV.ND.EDU] On Behalf Of Karen
Coyle
Sent: Tuesday, December 06, 2011 7:44 AM
To: CODE4LIB@LISTSERV.ND.EDU
Subject: Re: [CODE4LIB] Models of MARC in RDF
Quoting "Fleming, Declan" :
> Hi - I'll
On Dec 6, 2011, at 5:52 PM, Montoya, Gabriela wrote:
> ...
> I'd much rather see resources invested in data synching than spending it in
> saving text dumps that will most likely not be referred to again.
> ...
In a MARC-as-the-record-of-record scenario; storing the original raw MARC might
be h
On Tue, Dec 6, 2011 at 20:52, Montoya, Gabriela wrote:
> One critical thing to consider with MARC records (or any metadata, for that
> matter) is that it they are not stagnant, so what is the value of storing
> entire record strings into one triple if we know that metadata is volatile?
> As an
On 07/12/11 14:52, Montoya, Gabriela wrote:
Dream Team for Building a MARC> RDF Model: Karen Coyle, Alistair Miles, Diane
Hillman, Ed Summers, Bradley Westbrook.
As much as I have nothing against anyone on this list, isn't it a little
US-centric? Didn't we make that mistake before?
cheers
On Wed, Dec 7, 2011 at 1:49 PM, stuart yeates wrote:
> As much as I have nothing against anyone on this list, isn't it a little
> US-centric? Didn't we make that mistake before?
I wouldn't worry. A dream-team have no basis in reality, hence the
"dream" part. I'd like to see a Real Team instead, a
On Tue, Dec 6, 2011 at 10:23 PM, Alexander Johannesen
wrote:
> A dream-team have no basis in reality, hence the "dream" part.
Tell that to the 1992 U.S. Men's Olympic Basketball Team.
Mark
> > A dream-team have no basis in reality, hence the "dream" part.
>
> Tell that to the 1992 U.S. Men's Olympic Basketball Team.
So, the response to my suggestion of an unhelpful US bias is a US-based
metaphor?
I'll just consider my point proved.
cheers
stuart
I mean, have you *seen* Drexler dunk?
-Original message-
From: Stuart Yeates
To: CODE4LIB@listserv.nd.edu
Sent: Wed, Dec 7, 2011 06:50:28 GMT+00:00
Subject: Re: [CODE4LIB] Models of MARC in RDF
> A dream-team have no basis in reality, hence the "dream" part.
Tell that to
gt; To: CODE4LIB@LISTSERV.ND.EDU
> Subject: Re: [CODE4LIB] Models of MARC in RDF
>
> I'd suggest that rather than shove it in a triple it might be better to point
> at alternative representations, including MARC if desirable (keep meaning to
> blog some thoughts about progr
ards.
>
> (As an old-timer, I remember running the entire Univ. of California union
> catalog on 35 megabytes, something that would now be considered a smallish
> email attachment.)
>
> kc
>
>>
>> D
>>
>> -Original Message-
>> From: Cod
that MARC record, and the OCLC record identifier.
Brad W.
-Original Message-
From: Code for Libraries [mailto:CODE4LIB@LISTSERV.ND.EDU] On Behalf Of
Fleming, Declan
Sent: Tuesday, December 06, 2011 2:43 PM
To: CODE4LIB@LISTSERV.ND.EDU
Subject: Re: [CODE4LIB] Models of MARC in RDF
Hi
35 matches
Mail list logo