Weibel,Stu felt an urge to reveal at 3:20 PM -0500 on 1/27/98:
> Nonetheless, early implementers have identified requirements for certain
> key subelements. Rather than encourage proliferation of these common
> subelements, with each application employing slightly different
> nomenclature and semantics, some of the most commonly used subelements
> are identified here and presented in a standardised form. As can be
> seen, most of the 15 elements remain unqualified.
>
> The list of 'approved' subelements presented here does not in any way
> exhaust the possibility of such elements, but every attempt will be made
> to keep this list intuitive and succinct. Note that applications
> wishing to promulgate a formal set of additional elements can do so by
> specifying a formal scheme enumerating such subelements. Wide adoption
> of a given scheme (or lack of adoption)is one mechanism for the
> marketplace to signal desireable evolutionary paths for subelements,
> either within bounded communities or more generally.
Is there any possibility that some kind of simple meta spec file could be
linked to that would be machine readable, that is, an instruction code of
some sort, so that a client receiving metadata could load this file, cache
it perhaps (if it was being used on a site) and use this file to determine
how the various elements could be interpreted? Say that the metadata
contained something like:
<META NAME="DC.Creator.Original" SCHEME="MyScheme" CONTENT="foo">
<META NAME="DC.Creator.Digitization" SCHEME="MyScheme" CONTENT="foo">
<META NAME="Location.MyScheme" CONTENT="myscheme.sch">
and the file myscheme.sch contained instructions to the effect of:
"If the user wants to know *just* the DC.Creator, then give them
DC.Creator.Digitizer, unless an author search was used [say, in a library],
then return DC.Creator.Original"
Although of course it would be in some machine sort of syntax, such as
defineElement DC.Creator {
if QUERY("Author") {
DC.Creator = DC.Creator.Original
else
DC.Creator = DC.Creator.Digitizer
}
}
Something like that. My knowledge of programming languages is limited
almost exclusively to scripting languages, etc. so obviously someone else
would be better suited to figuring out a convenient, flexible language.
Still, I think this would be very effective and could potentially provide
even more useful information. The format would be standardized and could be
designed to be used in various systems.
--------------------------------a n--------------------
[ Jordan Reiter C I ]
[ mailto:[log in to unmask] t ]
[ "Tell the truth and run." e ? ]
[ Yugoslav proverb l u ]
-----------------------------------------l----o--------
y
|