>
> Rebecca writes:
>
>
> > I personally don't feel like there's been enough discussion about
> > qualifiers to officially bless these. I think there are too many
> > qualifiers in the qualifiers documents, potentially resulting in very
> > complex records.
>
> I agree with Rebecca. I'm in favor of experimenting with things,
> and I can imagine that in the future we might well have rather
> complex version of DC records, but to make this path the main road
> is, in my view, a mistake, and a distraction from one of the main
> design goals: a SIMPLE resource description record.
>
> Let's move cautiously here, and let the needs of the applications
> drive the direction. To me, that means simple first and formost,
> with an eye towards flexibility to allow elaboration as necessary
While I do think that Rebecca makes a good point for simplicity, and
that Stu justly agree with Rebecca and Preben justly with Stu, I still
find Jon's and Martin's paper extremely useful, in that it is a fairly
complete collection of schemes, types that has been suggested. As far
as I know I don't think that they themselves have seriously proposed
that http://www.roads.lut.ac.uk/Metadata/DC-SubElements.html should be
blessed with some typographical corrections. If that were the case
there would be no need for 28 hours imprisonment in an aircraft for
Australia.
The way to go about the sub-elements (or is it sub-fields) is in my
view to look at the various cross-walks between metadata systems to
find out what is needed in DC to successfully translate between, say
DC <--> GILS
DC <--> IAFA
DC <--> EAD
DC <--> MARC
and perhaps later also to pay some attention other ones like BiBTeX
and refer.
The algorithm would be to start with defining sub-elements that where
other systems directly corresponds with each other. Since they
correspond, they ought to be important, and they should be easy to
point out by experts on the gang of four: GILS, IAFA, EAD and MARC.
The sub-element set thus derived would constitute the CORE
sub-elements.
Yours,
Sigge
|