Thank you, Owen! A few comments interspersed...
Stephens, Owen wrote:
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!)
wow
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?
Not that I'm aware of. DCAP (as well as DCAM) are pretty much in their
embryonic stages and haven't had real world proof yet. There are APs
that use some of the DCAP concepts but not all, and in fact it would be
very difficult at this point to create a full AP for libraries since we
don't have our vocabularies all defined in RDF. So I agree that an
intermediate approach makes sense at this moment in time.
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?)
I think this is an excellent question, and one that needs to be
addressed by the DC community. It is incumbent on them to make the case
for their standards in a way that translates to a real motivation for
metadata developers. The DCAP document goes further in this direction
than other documents, but the benefits of DCAM are less clearly expressed.
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.
I'm not sure that AACR2 (or RDA) go much beyond usage guidelines. They
don't define data elements as such, and they don't provide a record
format. They are about making decisions about the description of
something. But I think I know what you mean, because we don't have
anything BUT the cataloging rules to go on so they seem to embody our
data definitions as well. But not the formal data definitions, which
then gets done after the fact in MARC. It's not a good approach to
define and manage these two standards separately.
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?
It's just an example, but I see that it's confusing. In fact, you could
have those kinds of instructions either in the DSP or the usage
guidelines, or in both. For example, you can use Dublin Core fields,
which have no limitations on repeatability or mandatoriness, but can
include rules in the usage guidelines that aren't enforced in the DSP.
However, I'll change this example to be about the ORDER of authors,
which makes more sense in guidelines. Does that sound better?
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.
Personally, I am totally for multiple APs for the library world. One of
the things that makes the cataloging rules so complex, and our records
so complex, is that they try to cover every possible type of resource
for every possible type of library. And therefore they fail for some
percentage of the cases. Your examples here make perfect sense to me.
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?)
The purpose behind the Singapore Framework for Application Profiles is
to make it possible to have interoperability between DCAPs even though
they can vary in many ways. The engineering concept is that this will
guarantee interoperability at a machine-code level. I honestly can't
comment on that since I don't think about things at that level of
abstraction/engineering. Even if the creation of APs using these
standards doesn't guarantee interoperability at a machine-code level, I
like the fact that we have some guidance in terms of defining metadata.
I see real value in the definition of properties and vocabularies
("controlled lists") in a standard way, plus the definition of value
types (plain text, structured, controlled vocabulary, complex), and the
various constraints (repeatable/not, mandatory/not). Beyond the
machine-processing issues, it would be useful for us to use these same
conventions when defining our metadata as a way to communicate better
between metadata communities.
Finally, it looks to me like RDA would benefit immensely from being
expressed as a DSP plus usage guidelines...
Amen.
And thanks again,
kc
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: [EMAIL PROTECTED]
-----Original Message-----
From: Code for Libraries [mailto:[EMAIL PROTECTED] On Behalf
Of
Karen Coyle
Sent: 04 November 2008 13:42
To: CODE4LIB@LISTSERV.ND.EDU
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
[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> http://www.kcoyle.net
ph.: 510-540-7596 skype: kcoylenet
mo.: 510-435-8234
------------------------------------
--
-----------------------------------
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
------------------------------------
