Quoting MJ Suhonos <[email protected]>:
Sure, my goal is simple in theory and complex in practice: take a
pile of MARC records and turn them into a set of DCTERMS (I'll avoid
reference to the older QDC notion) so that I can do interesting
things with them — the simplest use case being exposing a "record"
as a pile of RDF triples.
dcterms so so terribly lossy that it would be a shame to reduce MARC
to it. What we need, ASAP, is a triple form of MARC (and I know some
folks have experimented with this...) and a translate from MARC to the
RDA elements that have been registered in RDF. However, I hear that
JSC is going to be adding more detail to the RDA elements so that
could mean changes coming down the pike.
I started to create a MARC/RDA crosswalk out of the JSC document that
compares them, but there were catches: 1) the document wasn't specific
enough 2) there are going to have to be lots of 'if-then-else's
incorporated into it.
I am interested in working on "MARC as triples", which I see as a
transformation format. I have a database of MARC elements that might
be a crude basis for this. Again, some logic will be needed to get the
real meaning out of the MARC fields and subfields. I would appreciate
hearing from anyone who has done some or all of this.
kc
The main rationale behind using DCTERMS is that it is: a) more
expressive than DC, obviously; and b) it's more interoperable with
stuff like RDF than MODS, since it's based on the DC abstract model.
The main reason I'm looking at MARC->MODS->DCTERMS instead of the
known MARC->QDC crosswalk is because I can't read MARC worth beans
(245? 799? XYZ? What?). And the LoC MARC->MODS XSL does a nice job
of mapping and stripping out the stuff that I don't want to be
bothered with anyway.
Like I say, if I've misunderstood something, please do feel free to
correct me.
MJ
PS. Actually, Karen's post today is pretty close to the mark. I'm
building a prototype LibBase.
http://kcoyle.blogspot.com/2010/05/bib-data-and-semantic-web.html
On 2010-05-03, at 12:12 PM, Ross Singer wrote:
Out of curiosity, what is your use case for turning this into DC?
That might help those of us that are struggling to figure out where to
start with trying to help you with an answer.
-Ross.
On Mon, May 3, 2010 at 11:46 AM, MJ Suhonos <[email protected]> wrote:
Thanks for your comments, guys. I was beginning to think the lack
of response indicated that I'd asked something either heretical
or painfully obvious. :-)
That's my understanding as well. oai_dc predates the defining of
the 15 legacy DC properties in the dcterms namespace, and it's my
guess nobody saw a reason to update the oai_dc definition after
this happened.
This is at least part of my use case — we do a lot of work with
OAI on both ends, and oai_dc is pretty limited due to the original
15 elements. My thinking at this point is that there's no reason
we couldn't define something like "oai_dcterms" and use the full
QDC set based on the updated profile. Right?
FWIW, I'm not limited to any legacy ties; in fact, my project is
aimed at pushing the newer, "DC-sanctioned" ideas forward, so I
suspect in my case using an XML serialization that validates
against http://purl.org/dc/terms/ is probably sufficient (whether
that's RDF or not doesn't matter at this point).
So, back to the other part of the question: has anybody seen a
MODS <—> DCTERMS crosswalk in the wild? It looks like there's a
lot of similarity between the two, but before I go too deep down
that rabbit hole, I'd like to make sure someone else hasn't
already experienced that, erm, joy.
MJ
--
Karen Coyle
[email protected] http://kcoyle.net
ph: 1-510-540-7596
m: 1-510-435-8234
begin_of_the_skype_highlighting 1-510-435-8234 end_of_the_skype_highlighting
skype: kcoylenet
