> dcterms so so terribly lossy that it would be a shame to reduce MARC to it.

This is *precisely* the other half of my rationale — a shame?  Why?  If MARC is the mind prison that some purport it to be, then let's see what a system built devoid of MARC, but based on the best alternative we have looks like.

That may well *not* be DCTERMS, but I do like the DCAM model, and there are plenty of non-library systems out there that speak simple DC (OAI-PMH is one example from this thread alone).  Being conceptually RDF-compatible is just a bonus for me.

This would be an incentive for them to at least consider implementing DCTERMS, which may be terribly lossy compared to MARC, but is a huge increase in expressivity compared to simple DC.  Integrating MARC-based records and DC-based records from OAI sources in a single database could be a useful thing to play with.

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

This seems like it's looking to accomplish different goals than I am, but obviously if there's a MARC-as-triples intermediary that's workable *today* then I'd be happy to use that instead.  But I wonder: how navigable is it by people who don't understand MARC?  How much loss is potentially involved?

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

Yeah, that might be easier than mapping from MODS, though I'll have to see how much I can look at a MARC-based XSLT before my brain melts.  Hopefully it wouldn't take *too* much work.

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

Well, a MARC-as-triples approach would suffer from the same problem just as much, at least initially.  I think the issue of converting literals into URIs is an important second step, but let's get the literals into a workable format first.

I should clarify that my ultimate goal isn't to find a magical easy way to RDF, but rather to try to realize a way for libraries to get their data into a format that others are able and willing to play with.  I'm betting on the notion that the majority of (presumably non-librarian) users would rather have "incomplete" data in a format that they can understand and manipulate, rather than have to learn MARC.  I certainly would, and I'm a librarian (though probably a poor one because I don't understand or highly value MARC).

Naive? Heretical? Probably.  But worth a shot, I think.

MJ