 |
 |
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