An interesting announcement was made this past week that the DC and RDA communities will be working together to do the following:
- development of an RDA Element Vocabulary
- development of an RDA DC Application Profile based on FRBR and FRAD
- disclosure of RDA Value Vocabularies using RDF/RDFS/SKOS
The news isn’t exactly taking the library community by storm, but the commentary I have seen has all been of the “this is a good thing, I’ll follow this with interest” theme. But something bothers me about this plan, and I’m having trouble deciding exactly what it is I find, well, wrong in some way.
There’s nothing in the announcement that indicates the development of RDA proper will be affected by this work; in fact, the indication in the announcement that funding will be sought for the activities outlined implies the work is a long way off, likely entirely too late to have any real effect on RDA. This seems to be to be entirely backwards – trying to harmonize DC principles with RDA after the fact. Didn’t the DC community learn its lesson about the pitfalls of this approach when developing the Abstract Model, only realizing long after developing a metadata element set that it would benefit from an underlying model?
This general approach failed miserably with the DC Libraries Application Profile. There, the application profile developers wanted to use some elements from MODS, but weren’t able to because MODS doesn’t conform to the DCMI Abstract Model. So basically what the DC community said here was that application profiles are great, they form the fundamental basis of DC extensibility, but, oh yeah, you can’t actually use elements from any other standards unless they conform to the Abstract Model, even though are no approved encodings for even DC itself more than two years after the Abstract Model was released. OK then. Way to foster collaboration between metadata communities.
But maybe the DC community will change paths and realize flexibility and collaboration get more users than intellectual rigor. It’s sad in some respects, but true. It wouldn’t be the first time there’s been a major shift in the direction of the DCMI. I don’t know that this is a good thing, but I’ll certainly follow it with interest.
Posts
4 comments:
I think you are exactly right here, and this is an important point.
For better or for worse, we're one step at a time here.
Getting the RDA JSC to even _recognize_ that there is value in doing this is a big step.
Now, the next step will be.... are they going to realize what it takes to do this? Becuase I think you're absolutely right that it _can't_ be done after the fact.
To me--not an expert in DCAM, not at all--what really needs to be done is: making RDA formally rigorous enough to fit into the DCAM. And to me, the fact that it's DCAM particularly is less significant than the 'formally rigorous' part. If you outline what DCAM appares to call the "domain model" and the "element vocabularly" with enough precision for DCAM---it'll also be enough precision for a variety of other modern metadata usages.
But does the JSC really realize what it'll take to do this? Do they realize that it has to be done as an integral part of RDA, it can't be grafted upon after the fact and work? Do they realize the work it'll take to do this, starting from what you aptly call the "mess that is the set of RDA drafts right now"--only kind of sort of consistent to the FRBR model (a domain model which is only kind of sort of done in the first place)?
I'm not sure, and I'm not sure they would have agreed to it if they had! But I'm trying to be optimistic.
Jenn:
While I understand your skepticism, let me urge you to keep an open mind about this as we get beyond the initial brief announcement. In the meantime, a couple of points to ponder:
1. What is RDA proper? Is it the FRBR integration, the evolving element structure, the instructions? This mushiness is part of the problem, I think, and what the agreement signifies first is that the pieces must be separated, disentangled, and re-consituted in a way that works better for us. This should provide a much better level of explicitness and flexibility for all.
2. We purposely didn't include a timeline, because there's a great deal to do in defining what the work products are, who is best positioned to do the work, and who is interested in supporting the work financially. That said, some progress has already been made and funding is actively being sought. The intention is to have a significant piece done quickly enough to ensure the confidence and participation of the community. I think we have a shot, actually.
3. As for the point about DC's late realization that it needed a model, well, sure, we're happy to admit that--but we did, and now we have a model, and others seem to find it pretty useful. I'm not one to cast aspersions on changes in direction--it's one sign of that flexibility you seem to be looking for, is it not? ;-) The fact is, we're all learning as we go.
4. As a bit of a clarification, the problem with incorporation of MODS elements was less conformance with the Abstract Model and more that they weren't formally declared properties with URIs. This is still an issue with MODS, as well as many other metadata formats/element sets, and has been a considerable deterrent to progress with Application Profiles in general.
As for recommended encodings, well, there is work in progress--do keep an eye on the lists for the public comment period.
I hope we'll be able to reassure you and the rest of the community as we go along. I'm pretty excited by this opportunity and very eager to get going on it, and I know the other participants concur.
Regards,
Diane
You'll be happy to know then, that the meeting has *already* resulted in modifications to the RDA drafts in light of compatibility. How does that sound? :-)
Of course, you're absolutely right that RDA needs to be done right from the start. We hope that this will be possible, thanks to this meeting.
Thanks, Diane and Mikael, for the comments. It's great to get more information from those close to this initiative - I know I have tons of questions and I'm sure others do as well.
It's wonderful to hear the plan is for this to be an iterative process. That said, we've seen before that RDA intends to do things a certain way (e.g., FRBR harmonization) and ends up falling a bit short. Let's hope the "more minds" approach will be successful here.
Something you said, Diane, raised a bit of a red flag for me, though. You asked what RDA is - the rules, the underlying model, something else? I'd say something like 99.937256% of people out there would say the answer to that question is "the rules," and if this initiative moves forward with anything other than that, you've lost all of those people. Gone. They'll no longer see value to them in this work.
I see now I glossed over an important point in the original announcement. The first activity mentioned is "development of an RDA Element Vocabulary." (Isn't DC out of the business of vocabularies?) I really hope this doesn't mean this initiative is planning on creating a structure standard out of RDA, which is a content standard. If whatever harmonization happens here happens on RDA as a structure standard, you've REALLY lost all regular RDA users. It's taken us enough time to sort out the difference and educate people about it - using the same label for these two different things would be nothing short of a disaster.
I guess I'm just concerned that this work needs to be done in such a way as to embrace the cataloging community and not alienate it. There are some amazingly smart people working on this, so I'll retain hope that this goal can be achieved. Keep us posted, please!
Post a Comment