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.
Thanks Carl.
This all sounds very sensible to me and is very much in line with the one
page document we used as the basis for discussions at DC-7. I'm happy to
vote for or against proposed qualifiers on the basis of these guidelines
(it's what I was planning on doing anyway), i.e I intend to vote against
qualifiers that do not clearly fall within these guidelines.
Andy.
> 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
>
>
Andy
--
UK Office for Library and Information Networking
University of Bath, Bath, BA2 7AY, UK Voice: +44 1225 323933
www.ukoln.ac.uk/ukoln/staff/a.powell Fax: +44 1225 826838
Resource Discovery Network - www.rdn.ac.uk
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|