 |
 |
QDC basically represents the same things has dcterms, so you can probably just take the existing XSLT and hack on it until it until it represents something that looks more like dcterms than qdc. That won't address of the issue of breaking up the MARC into individual resources, however. You mention that you are looking for the short hop to RDF, but this is just going to give you a big pile of literals for things like creator/contributor/subject, etc. I'm not really sure what the "win" would be, there. -Ross. On Mon, May 3, 2010 at 12:27 PM, MJ Suhonos <[log in to unmask]> wrote: > 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. > > 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 >>> >