Thank you, Carl!  

In a general sense (and I do not want to get into the specifics of your
analogies and examples here), this is EXACTLY what we need now -- a
clear, concise statement of the general principles we promoted in
Frankfurt that we can all understand and (hopefully) agree on.

In addition to what you have covered, I might want to add a sentence or
two to the effect that this statement of principles deliberately avoids
introducing a specific nomenclature for qualifiers (eg, "Element
Qualifiers" versus "Semantic Refiners" versus "Encoding Value
Qualifiers" or whatever).  Rather, we expect our understanding of
qualification and of the modes and consequences of its use to evolve
over time and with experience.

The vagueness of this statement is a virtue. It reflects our current
level of understanding and consensus more honestly than the longer,
more specific, and thus more controversial draft of the reference model
currently on the table.  It also avoids distracting our attention in
this crucial voting phase with new (ie, new for DCMI) principles and
entities, such as Object Types, which we may very well eventually
decide are usable and desirable, but have yet to be considered,
understood by all, and approved.  I would suggest, therefore, that we
focus for now on getting these two fundamental principles right and
postpone discussion of more elaborate reference or data models for
later.

After the vote, then, I do think it might be wise to re-examine and
adjust this statement of principles, before release, in light of what
we have collectively deemed to be in conformance.  Such an additional
step in an ongoing, iterative process is what I believe Carl meant in
an earlier posting (perhaps misleadingly) by "reverse engineering", and
I do NOT think this need be open-ended or take weeks and months.  Extra
step or no, we need to consolidate our collective understanding of
principles, lest as individuals we later find it difficult to explain
or defend our collective result.

Refocusing our attention on this statement offers us a sensible way
forward.

Tom


On Fri, 14 Jan 2000, Carl Lagoze wrote:
> 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
> 
> 

_______________________________________________________________________________
Dr. Thomas Baker                                            [log in to unmask]
GMD Library
Schloss Birlinghoven                                           +49-2241-14-2352
53754 Sankt Augustin, Germany                              fax +49-2241-14-2619



%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%