On Fri, 25 Oct 1996, Peter Graham, RUL wrote:
> PRO:  Remembering Godel's proof, a system cannot be fully described in
> the language of the system itself.  

Adding a META-ELEMENT to DC doesn't change this fact, but just gives us
yet another element with which to either be complete or consistant with
(but not both at the same time). Though I must admit its the first time
I've seen Godelian theory brought to bear against metadata...

> a.  Language is a good example (see
> thread on Element Names).  What is the language of the element names,
> and what is the language of the content fields of the elements (and of
> the schemes, roles, etc.)?  These are two different questions (and are
> unrelated to the LANGUAGE element of the DC which refers to the work
> being cataloged by the DC record).  A meta-element could briefly
> indicate each of these, and in its absence a user (automated or human)
> could assume English as a default.

_A_ meta-element might not be satisfactory.  For example, what if you had
multiple titles in different languages and character sets?  Each one would
require separate handling wouldn't it?  Much better IMHO to have a
language and a charset sub-element qualifier if necessary (with defaults
of EN and ISO-8859-1 for backward compatibility).  That way you can switch
language and charset on an element-by-element basis.  And multiple
meta-elements just sounds like a headache waiting to happen.

> Example:  a French metaloger specifying
> the subject of a document as being "tea" without the word being
> interpreted as "the" by a person or webcrawler (or consider "pet", or
> in German, "war").  

This means that we're expecting language specific robot generated indexes
to be generated, right?  I'd guess that for the most part the
international search engines will just grab the English version and junk
the other languages.  It'll only be national/regional services that make
use of the multilingual stuff.  Sub-element qualifiers for language and
charset will handle this fine.
 
> b.  Specification of schemes:  it seems likely  that metaloging will
> be done according to rules, often, and not just element by element.
> Allowing specification of, say, "scheme=A2", "scheme=RMV," and
> "scheme=LCSH" could save labor by avoiding repetition and achieve human
> readability by reducing clutter.

But we might want to specify multiple rules or use different rulesets for
different bits of DC.  Again, this is what sub-elements are for IMHO; it
makes it more readable because you specify what external rules you're
using (if any) right next to the value.  And I'd expect that most hand
generated DC will be using the defaults and few of the rules (we can't
expect everyone to suddenly read AARC2 now, can we?)
 
> c.  Defaults:  more elaborate specification of defaults could be a
> meta-element issue.

Explain please?  Surely default is just that; a default.  We don't want
something to mess with the definition of what a default is as it will make
it more difficult to support in code.
 
> d.  Foresight:  it seems likely that the DC will grow and become more
> complex rather than less once use becomes active.  Looking ahead to
> the need for overall statements might be wise at this time.

I'd rather have DC evolve a little bit at a time (with huge great fights
to keep it simple :-) ).  We just don't know what sort of things we might
need until its out there in constant use, so I'd prefer not to second
guess the future requirements too much and introduce new elements that
there's no clear need for.  And I'm afraid I don't see a clear need for
the meta-element yet.  Sorry.
 
> The question asks itself:  in what language will the meta-element be
> phrased, and what defaults will it have (the bird of recursion rears
> its ugly head).  At this point, with the slightly more rule-bound and
> meta-cataloging intent, standard cross-cultural terms or even numbers
> might be relevant for use.

Eeek!

Tatty bye,

Jim'll

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Jon "Jim'll" Knight, Researcher, Sysop and General Dogsbody, Dept. Computer
Studies, Loughborough University of Technology, Leics., ENGLAND.  LE11 3TU.
* I've found I now dream in Perl.  More worryingly, I enjoy those dreams. *