Given Stu's latest statement on process and the lack of understandable
guidelines, I'm having a heck of a time participating in the voting process.
So's that I don't get accused of being a whiner and complainer, I'm going to
try to propose a solution. What follows is an attempt at guidelines for the
qualification process. Without agreement on such guidelines (not these
exactly but someting of this nature) and the articulation of those
guidelines in the public document that lists the qualifiers, I don't see how
we can proceed with a voting process and I certainly don't think that I can
participate in it. I'm going to frame this as if it were the introduction to
the public release of the results of our document publishing these
qualifiers.
Start of introductory text for the qualifier document......
This document contains the results of a recently completely process to
develop a set of qualifiers for the Dublin Core Element Set (DCES). The set
of qualifiers listed in this document are intended as a set of minimal
qualifiers that illustrates principles of good practice for qualification of
the DCES. It is expected that many additional qualifiers will independently
be developed over time by other communities and that this minimal set will
serve simply as a seeding of a larger qualifier database, rather than a
specification of some distinguished set.
Intereropability across Dublin Core descriptions will only be possible if
the qualifiers developed by individual communites follow common guidelines.
The general 'guiding principle' for these guidelines is as follows. An
agent or client should always be able to ignore any qualifier, and use a
description as if it were unqualified. This may result in loss of specific
meaning, but not incorrect interpretation. The logic for this is that there
will inevitably be situations where an agent or client will encounter a
Dublin Core description with an unknown qualifier (one that has been
developed by another community). Interoperability in such an environment
depends on such ability to ignore domain specific qualification and rely on
cross-domain generalizations (the basic unqualified elements).
Given this guiding principle, qualifiers for Dublin Core elements fall into
two broad categories defined below.
1. Value Encoding - These are qualifiers that aid in the interpretation of a
value for an element, independent of the element to which the value is
attached. For those familiar with programming this is analogous to data
typing. The data types "integer" and "real" make it possible for a compiler
or interpreter to interpret the encoding of a stream of bits, independent of
whether that stream of bits is attached to a variable that semantically
expresses age, temperature, or something else. Another easily accesible
example of an encoding scheme, outside the programming domain, applies to
personal names. An encoding scheme "last name first" tells how to interpret
the string "Weibel, Stuart" regardless of where that string occurs (e.g., an
author, publisher, programmer, actor, etc.).
This definition combined with the guiding principle described above makes it
possible, then, to describe a valid qualifier that can serve as a value
encoding. It is one that 1) aids in the interpretation of a value
independent of the element to which that value is attached and 2) if a
specific value encoding qualifier is unknown to a certain client or agent it
can be ignored, yet the respective value can still serve as a proper value
for the element to which it is attached. As stated above, this is essential
since not all qualifiers will be known to all communities and
interoperability relies on the ability of clients to ignore qualifiers; the
effect of which will be loss of specificity without loss of correctness.]
2. Element Refinement - These are qualifiers that increase the specificity
of the meaning of an element but, and most importantly, do not extend or
alter the meaning of an element. For those familiar with data typing in
programming, this is analogous to sub-typing, which makes it possible to
specify that some category is more specific than a broader category. The
effect is that the more specific category shares all the attributes of the
broader category and, therefore, can be treated as if it were the broader
category (i.e., if 'b' is a subtype of 'a' then all things that are of type
'b' are also of type 'a' - but the inverse is not true).
This definition combined with the guiding principle describe above makes it
possible, then, to describe a valid qualifier that can serve as an element
refinement. It is one that 1) increases the specificity of the meaning of
an element and 2) if a specific element refining qualifier is unknown to a
certain client or agent it can be ignored, and the value associated with the
qualified element can be treated as if it were the value of the unqualified
(broader) element. An example and counter example are illustrative. (Both
of which are purposefully not within the Dublin Core Element Set) since
examples within this context are provided later in this document). Assume a
semantic category (element) 'weather' with the description 'a specific
atmospheric condition'. A proper element refinement qualifier for this
element would be 'cloud cover' (e.g. partly cloudy, clear), since cloud
cover is a 'type of' atmospheric condition. An incorrect element refinement
qualifer for this element would be 'observer' or 'reporter' of the weather
condition (e.g., a person who reported the weather, such as 'Stu Weibel said
it was partly cloudy') since that person is not a type of weather condition
and the association of the value 'Stu Weibel' with the unqualified element
'weather' is a violation of the guilding principle.
The remainder of this document lists the seed set of qualifers articulated
by the DCMI that clearly conform to these principles. Every qualifier is
classified as either a value encoding or an element refinement. Communities
may, therefore, use these qualifiers with confidence that they will
interoperate according to the general notion interoperability defined within
the guilding principle outlined above. Communities may also use these
qualifiers as examples to guilde their own development of 'principled'
qualifiers for the Dublin Core elements
End of suggested text.....
In my humble opinion this is not "reverse engineering" or "theory" but
rather common sense and it represents something from which I can write
programs that conform to it. I am willing to vote on qualifiers based on
these principles. If somewhat wants to articulate other principles that can
be used as the basis for constructing machinery to use Dublin Core
descriptions, then I'd like to see them so I can vote on qualifiers based on
them.
Carl
----------------------------------------------------------------------------
Carl Lagoze, Digital Library Scientist
Department of Computer Science, Cornell University
Ithaca, NY 14853 USA
Phone: +1-607-255-6046
FAX: +1-607-255-4428
E-Mail: [log in to unmask]
WWW: http://www.cs.cornell.edu/lagoze/lagoze.html
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|