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