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