Philip,
These are good questions. Some of them may not have answers at this moment in time, and for sure I cannot answer them all. But maybe I can give some background information, and then I'll tackle some specifics within your message. But I do hope that others chime in, especially if I get anything wrong. The basic framework that is being considered is this (and I'm going to give it somewhat backwards because it might make more sense that way): The library cataloging rules (of any stripe) are instructions on how to make decisions about a group of data elements (title, author, series, etc.). In AACR and RDA (currently), those data elements are not defined separately from the rules themselves. So we have a single document that has the rules for the library community as well as its data elements, although it takes some work to pull the data elements out of the text. Because our cataloging data will need to be expressed in a machine-readable form, and because it should be defined in such a way to be compatible with Web applications, we need to formalize the data elements. This means that rather than having the data elements just assumed in the textual guidance, they need to be defined in themselves in a usable way. Deciding on that usable way, however, means making certain decisions. One of those decisions is the abstract framework, something that most of us mere mortals will never encounter. It's the basic structure that will be used to define the data, in the way that there are structures like IP packages that define the basis for the Internet. The abstract framework is important because if it is followed then we have a guarantee that the data we create can be understood by programs because it has certain characteristics, in the same way that Internet applications know what to do with a packet. The data elements are then created in conformance with the abstract framework. The application profile is a particular community's selection of data elements and rules. So if you can imagine that we have defined a fairly large number of data elements that can be used for bibliographic applications, but not all bibliographic applications will be interested in all of them. So the application profile says: I'm ProfileX and I will use: data1, data78, data42. Another profile can make a different selection. Profiles are not records, they are a statement of all of the data elements that a community will use in its records. So if we combined all of the data elements from all of the bibliographic applications, like MARC21, UNIMARC, Dublin Core, DACS, EAD, etc., and put those in a registry, then the MARC21 community would define itself as being a set of data elements, and EAD would define itself as a different set. But where the data elements they choose are the same, they are then using the very same data element. Or, if they differ, it may be possible to know how they differ if the basic data elements have been created with some semantic relationships, like "uniform title is a kind of title." Therefore, what it comes down to is we need four things to have a bibliographic application: - an abstract model - formally defined data elements - an application profile - implementation guidance I'm sure this isn't a complete explanation, but I'm happy to work with you (all) on it, since I think we need an explanation that is a) correct and b) understandable by most. now... Philip Davis wrote:
Why is it necessary to develop a separate application profile when DC already has a model, schemas, a user guide and encoding guidelines?
Does the above explanation help you answer this? It seems like your use of "application profile" wasn't the same as what I described. However, it IS quite possible that the DC abstract model will be usable for RDA -- that's partly what needs to be tested by trying to create the RDA vocabularies.
How will the present unfinished state of RDA, FRBR and FRAD affect the proposed developments?
I don't think anyone knows. The folks working on RDA have produced a data element list (http://www.collectionscanada.ca/jsc/docs/5rda-elementanalysis.pdf) so they appear to have an idea of what the data elements are. FRBR and FRAD are bigger questions, I think. There are a few attempts to actually code FRBR - one as RDF and one as object-oriented - but it isn't clear if FRBR actually translates into something machine-usable in the sense of being able to code it.
What changes will be sought to these standards in order to maximize the quality of the vocabularies and application profile?
That's partly what will be learned by going through the process. If anyone has already formed some ideas about needed changes, I'd be very interested to hear them.
RDA contains many terms of use in a metadata schema. Will other systems be consulted in the preparation and organization of the vocabularies? I think particularly of the faceted classification that was prepared for use with Library Science Abstracts.
I don't understand this question. It may be about the various vocabulary lists (physical types, agent roles, the terms for pages and parts). I feel strongly that vocabulary lists should be defined outside of any particular standard so that they can be shared where appropriate. So I would like to see many different communities creating their lists (for which we will need an agreed standard format) because I think it will, in the long run, promote data sharing.
In terms of a metadata system, AACR would be seen as essentially the user guide element. RDA is intended to replace AACR. Will the role of RDA be extended to include other parts of the system? Will it be reduced to confine RDA to being a user guide?
Again, I'm not sure I understand the question, but the instructions in RDA are indeed a kind of user guide.
An important principle of Dublin Core is the one-to-one principle. The record (metadata description set) covers one manifestation of a resource. How will the projected system deal with the other RDA/FRBR group one entities of work, expression and item?
That's really a record creation question. And one for which I don't think there is an answer. We do not currently have a "FRBR-structured" bibliographic record and RDA appears to be guiding us to a record that is, in the one-to-one sense, equivalent to the record that was created under AACR. Someone more familiar with DC should describe the complexities of one-to-one .
It is still planned to publish RDA in 2009. Is this likely to be in a conventional version, or is it possible that the metadata form will be ready by then? Am I right in thinking that, when the metadata form becomes available, the conventional form will be withdrawn?
The RDA scheduled for 2009 is still supposed to be a "web-based product" as well as a print product. (I know that there was a bid out for the creation of the web-based product, but I haven't seen any specifications that would explain better what form that product will take.) The creation of the metadata form should *enhance* these products, but does not by any means supplant them. At this point it isn't known if the metadata form will have any direct effect on those products, and most likely will not in 2009. It could make it easier in the future to create applications for bibliographic data, and it really should make it easier to update the standard and related applications (without having to wait years for a new version to be published). I personally am hoping that it will help us *truly* implement RDA as an application (because I don't think we can do that with MARC21, but that's my opinion). Well, that's a lot, but I really appreciate the set of questions you gathered -- I think they thoroughly covered the topic! Thanks, kc -- ----------------------------------- Karen Coyle / Digital Library Consultant [EMAIL PROTECTED] http://www.kcoyle.net ph.: 510-540-7596 skype: kcoylenet fx.: 510-848-3913 mo.: 510-435-8234 ------------------------------------
