I don't know, maybe the "dumb" in the subject line refers to me but you've
got me all confused here. You've given me a wealth of information in
natural language that I don't know how to turn into a mechanism for dumbing
down. My understanding, using as syntax neutral terms as possible is:
- we've got attribute/value pairs.
- the attribute may be either one of the DCES element (e.g., creator) or one
that is a sub-class (e.g. illustrator) of one of those elements. Dumbing
down allows the client who might know nothing about the semantics of the
sub-class (what the hell is an illustrator) except for the fact that it is a
true sub-class to ignore its "special" semantics and assume that it is the
same as the semantics of the primitive element class.
- the value may be either a primitive type (string of tokens) or one that is
a specialized type (e.g., enumerated list (e.g., LCSH), pattern matched
string (e.g., ISO8601), structured type (e.g., first and last names), some
other type). Dumbing down allows the client who might know nothing about
the specialized type to coerce it to the primitive type - reduce it to a
sting of tokens and then index those tokens.
I maintain that all clients are essentially dumb, in the sense that no
client will know about all qualifiers. Therefore, we are faced with the
- we must clearly formulate a dumb-down rule and apply it to every qualifier
so that dumb (all) clients can do some thing sensible with instances of DC
- we must come up with some other rule that allows the dumb (all) clients to
process instances with qualifiers that it knows nothing about.
- we accept the fact that the DC world will fragment into non-interoperable
community-specific and discipline specific islands (exactly what I thought
we were trying to avoid).
I want to stress again that I'm not talking about a distinction between
clients that understand qualification and those that don't. I'm talking
about all clients since no client will understand all qualification.
Carl Lagoze, Digital Library Scientist
Department of Computer Science, Cornell University
Ithaca, NY 14853 USA
E-Mail: [log in to unmask]
> -----Original Message-----
> From: Simon Cox [mailto:[log in to unmask]]
> Sent: Wednesday, December 01, 1999 9:43 PM
> To: [log in to unmask]
> Subject: Re: How dumb is dumb?
> In an instance like this
> Element=Creator Value="name:Renato Iannella; Affiliation:DSTC"
> the string "name:Renato Iannella; Affiliation:DSTC" is NOT a creator,
> it is an *identifier*for* a party who acted as a creator in
> this instance.
> The question should rather be whether "affiliation" is a
> legal part of
> an *identifier* for a party. I would submit that, in many
> particularly in a scholarly setting, it most certainly is.
> In some other communities the affiliation at the time of
> writing is of
> little interest, so they have other ways of distinguishing
> one Renato Ianella
> from another, such as birth and death dates, place of birth,
> Social Security Number,
> even eye-colour and shoe size perhaps (though I don't think
> we would recommend
> those as components of an identifier for interoperability
> purposes ;-))
> But be clear about what this string actually is - it is NOT a
> (that is the nature of the relationship between the value and
> the resource)
> it is not even a party (though that is the DC Type of the
> resource which
> is the object of the assertion), it is actually an *identifier*, in
> which case it shall contain whatever is needed to make it adequately
> unique in context, which might include affiliation.
> Carl Lagoze wrote:
> > Also, and again sorry for missig some email, are we still
> acceptint the fact
> > that affiliation is a legal part of a value for "creator"?
> Maybe its just
> > your example, but sorry this breaks dumbing down unless I'm missing
> > something again?
> Best Simon