 |
 |
Hi Karen, Yes - the document on DCAP makes sense (this maybe the first time I've ever uttered these words on a first reading of DCMI documentation - so well done!) There are parts of this that I definitely think would be beneficial for library data. Specifically the analysis of metadata against schemes that already exist, and the development of a Description Set Profile (in a machine readable format). I would question what the benefit of doing a full DCAP is as opposed to doing the bits that are clearly of practical value. Although I buy the argument that it they promote sharing/linking of data in theory, I haven't seen any real-world examples of this - has SWAP had more of an impact because there is a DCAP for it? If we were starting from scratch a DCAP would be (at least) as good a way as any other of capturing stuff like functional requirements and Usage Guidelines - but since these don't actually add to the functionality of the metadata scheme you end up with as far as I can see, where we already have this stuff in other forms (as suggested in the Usage Guidelines) then what would be the tangible benefits of restating for a DCAP? (I suppose the flip side of this is - would it be much work to do so?) Touching on the Usage Guidelines - I'd question whether the example given of AACR2 as an existing set of usage guidelines which you could refer to in the DCAP is completely accurate? Doesn't AACR2 hold a mixture of things that are usage guidelines, and things that would live in the DSP? If this is so, it may be worth being explicit about this to avoid misunderstandings. Further on the Usage Guidelines, one of the examples of a possible guideline is " For works of multiple authorship, the order of authors and how many to include (e.g. first 3, or no more than 20)". I'm not clear why you would express 'no more than 20' here, rather than as part of the relevant Description Template in the DSP? In terms of the library world, a question that occurs is that if we went down this route, would we find that we ended up with a single DCAP for libraries? As I think about it I wonder if we would find multiple DCAPs were required - perhaps Public Libraries would have a different DCAP to Research Libraries. Possibly more likely different types of collections would require different DCAPs. For example, it seems likely to me that the Functional Requirements for a rare books collection is different to that of the DVD collection. Further, it seems likely to me that the requirements for the DVD collection in my local public library is different to that of the DVD collection at my local media-arts college. If this is the case, what are the implications of mixing DCAPs within or across libraries? How would different DCAPs work together? What would be the implications for sharing records? Am I looking for problems here, or anticipating real issues? (I did read the document on Interoperability, but not sure I understand what it is getting at yet - however, I'm not sure it really is about this kind of interoperability?) Finally, it looks to me like RDA would benefit immensely from being expressed as a DSP plus usage guidelines... Owen Owen Stephens Assistant Director: eStrategy and Information Resources Central Library Imperial College London South Kensington Campus London SW7 2AZ t: +44 (0)20 7594 8829 e: [log in to unmask] > -----Original Message----- > From: Code for Libraries [mailto:[log in to unmask]] On Behalf Of > Karen Coyle > Sent: 04 November 2008 13:42 > To: [log in to unmask] > Subject: [CODE4LIB] [Fwd: Fwd: [DC-GENERAL] DCMI News 3 November 2008] > > Folks, two new documents have been published on the Dublin Core web > site, and I would very much like to get any comments you have on them. > Officially, comments must be sent to the dc-general list (details > below), but if there is discussion on these lists, I can summarize it > there. > > The first document is one I worked on -- painfully, I must say -- that > attempts to explain the DC concept of Application Profiles. These are > concepts we want to apply in the DC/RDA work, and my personal question > to you all is: DOES THIS MAKE SENSE? Can we use this in our metadata > environment? What's missing, what doesn't work, what needs > clarification? > > The next document addresses something I blogged recently: > http://kcoyle.blogspot.com/2008/10/semantics-of-semantic.html > which is some confusion caused by the use of the term "semantic web." > This document is related to the Application Profile document in that it > defines what we need so that different metadata sets can be > interoperable, another very important point for those of us working in > the library systems area. The document is from an engineering point of > view in its details, but the general concepts are quite common > sense-ible. Again, please let us know if there are areas that need > clarification. > > Given that this is election day, may I suggest that a printout of one > or > both of these documents will occupy you fully while you are in line > waiting to perform your patriotic (and moral) duty. VOTE! READ! EVOLVE! > > Thank you, > kc > > _____ > > "Guidelines for Dublin Core Application Profiles" published as a > Working > Draft > > 2008-11-03, The new DCMI Working Draft > < http://dublincore.org/documents/2008/11/03/profile-guidelines/ > > "Guidelines for Dublin Core Application Profiles" describes the > key components of an application profile and walks the reader > through the process of designing a profile. Addressed primarily > to a non-technical audience, the guidelines also provide a > technical appendix about modeling the metadata interoperably > for use in linked data environments. This draft will be revised > in response to feedback from readers. Interested members of > the public are invited to post comments by 1 December 2008 to the > < http://www.jiscmail.ac.uk/cgi-bin/webadmin?A0=dc-general > > DC-GENERAL mailing list, including "[Public Comment]" > in the subject line. > > _____ > > "Interoperability Levels for Dublin Core Metadata" published as a > Working Draft > > 2008-11-03, < > http://dublincore.org/documents/2008/11/03/interoperability-levels/ > > "Interoperability Levels for Dublin Core Metadata", published > today as a DCMI Working Draft, discusses the modeling choices involved > in designing metadata applications for different types of > interoperability. > At Level 1, applications use data components with shared natural- > language > definitions. At Level 2, data is based on the formal-semantic model of > the > W3C Resource Description Framework. At Level 3, data is structured as > Description Sets (i.e., as records). At Level 4, data content is > subject to > a shared set of constraints (as described in a Description Set > Profile). > Conformance tests and examples are provided for each level. The Working > Draft represents work in progress for which the authors seek feedback. > Interested members of the public are invited to post comments by 1 > December > 2008 to the < > http://www.jiscmail.ac.uk/cgi-bin/webadmin?A0=dc-architecture > > DC-ARCHITECTURE mailing list, including "[Public Comment]" in the > subject > line. > > Thank you! > kc > > > - > -- --- > Karen Coyle / Digital Library Consultant > [log in to unmask] <mailto:[log in to unmask]> http://www.kcoyle.net > ph.: 510-540-7596 skype: kcoylenet > mo.: 510-435-8234 > ------------------------------------