Quoting MJ Suhonos <[log in to unmask]>:
> 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 <[log in to unmask]> 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
[log in to unmask] 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
|
