Thanks Karen - some further comments (cross posted to the DC-RDA list as
it feels like I'm encroaching on this territory - original postings are
below):
Two of the issues I raised I think relate to the question of what should
be in the 'usage guidelines':
1. Are AACR2/RDA 'usage guidelines' or a mixture of stuff that should be
in DSP and usage guidelines?
2. Would you encode a restriction like 'books may have no more than 20
authors' in the DSP, and also state it in the usage guidelines?
I feel like I'm getting a bit picky here, but I wonder if it gets to the
heart of why one should adopt the DCAP approach rather than the approach
we currently have for RDA/AACR2 + MARC
RDA at least (and I think AACR2 but don't have my copy to hand) make
statements about elements. To take an example para 1.4 of the RDA draft
lists 'mandatory elements'. Clearly if we did a DCAP for RDA, this would
be first listed in the DSP. From what you say, it would still be valid
for the statement to appear in the Usage Guidelines.
However, this raises the possibility of inconsistencies, and thus
disagreements, about how you use elements etc. It also adds redundant
effort of course in keeping two things up to date.
On the otherhand, you clearly do need a human readable version of the
standard - if we talk about library cataloguing, you don't want to give
a cataloguer a copy of the DSP to refer to, but something a bit more
(human) usable, which I'll call the 'manual'. It seems to me that
ideally this 'manual' combines information from the DSP (in a human
readable format) with the usage guidelines, and that the usage
guidelines should not repeat information already encoded in the DSP. I
suppose what I'm thinking of is establishing something like 'good
practice' for the usage guidelines, and that these would say 'do not
repeat information that is already encoded in the DSP'
However, given that the usage guidelines currently can/do repeat
information from the DSP, then I think the example you give on usage
guidelines containing advice on the maximum number of authors is fine -
and should stay in, although perhaps with a note highlighting the fact
that this limitation may or may not also be encoded in the DSP.
Does this make sense?
Owen
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: [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
>> ------------------------------------
>>
>
>
>
--
-----------------------------------
Karen Coyle / Digital Library Consultant
[log in to unmask] http://www.kcoyle.net
ph.: 510-540-7596 skype: kcoylenet
fx.: 510-848-3913
mo.: 510-435-8234
------------------------------------
