There are several inlocking themes expressed in Jose's remarks. I'd like to
offer my own understanding of the landscape by suggesting the following
models. I'll say at the outset that I believe that these models, rather
than being mutually exclusive, *all* are in place right now. This is a
feature, not a bug, but it often leads us to unproductive arguments.
The coexistence of these models is evidence of a diverse ecology with many
niches. Needless to say, the boundaries among these model are not distinct;
rather there is a continuum with shadings and shadows (and my off-the-cuff
analysis may well have failed to identify other discreet models as well).
*** Model I.***
DC-MES as a primary metadata format, playing a central role with other
packages added to enrich the core functionality or to extend its scope.
This model is perfectly adequate to accomodate many applications without
legacy metadata, or legacy applications willing to sacrifice the cost of
change for the benefit of simplicity and/or easier Web interoperability.
Examples include many of the existing DC applications, including, notably,
the AGLS work in Australia, and the government metadata initiatives in
Denmark, Finland, and other places. It is my hope and expectation that many
important metadata applications that are evolving on the Web will fall in
this category, and encouraging this seems to me an appropriate investment of
effort.
If we could design a perfect, consistent world, we'd all like there to be
exactly one, useful-for-everyone, cheap, and optimally efficient standard.
DC-MES (including qualifiers and auxilliary packages) is not the perfect
realization of these goals, but it is certainly the closest low-resolution
solution in the current marketplace and will continue to evolve toward these
goals. I can, in good conscience, urge metadata designers of novel
applications to adopt this perspective to the extent that it can meet their
functional requirements, and to encourage them to develop DC-oriented
solutions to fill in the gaps that exist between current DC capabilities and
their particular functional requirements. It is one of the goals of the
Dublin Core Metadata Initiative (DCMI) to provide a forum to help focus the
expertise necessary to fill in these gaps, and early efforts in this
direction (the DC-Education group, for example) are encouraging.
*** Model II.***
DC-MES as a switching language, serving as a primary format in some
applications, and as a secondary format for the purposes of search
interoperability or exchange.
We know that DC-MES does not now, and cannot ever, satisfy every need of
every application or sector or domain, but it can nonetheless provide an
effective "digital tourist" pidgin language for applications that have
similar core semantics (with additional domain specific extensions). The
relationship of the MARC standards and DC, or the parallel metadata
developments within the MPEG community are examples of this model, and there
are others.
This model supports the goal of search interoperability, but will probably
not do very well at the level of interchange interoperability. That is, a
user is likely to be able to find useful resources in two disparate
applications that use DC in this way, but the two applications are unlikely
to be able to share their records without significant programming
conversion. Widespread deployment of registries and formal,
machine-readable schemas in an arhitecture such as RDF will, it is hoped,
prove me an unwarranted pessimist. Nonetheless, for the moment, mixing and
matching schemas will be a burden requiring rather more sophisticated
software capabilities than is currently common.
*** Model III.***
DC-MES as a competing technology, implying duplication of systems,
imperfectly overlapping semantics, possibly incompatible architectures, and
probably quite different value networks (by this I mean radically different
cost models, use contexts, access models, and the like).
This state is to be avoided wherever possible, of course, but it inevitably
will occur. It may be less problematic to the extent that, if the value
networks are radically different, these may simply be thought of different
ecosystems entirely, with non-intersecting niches. Often some parts of them
will intersect, however, and disparate architectures and standards will
introduce costly friction in the information cycle.
******
At the end of the day, the major reason for metadata can be thought of as
reducing friction in the information cycle. The continuum of models hinted
at here involves tradeoffs among local requirements, domain-specific
semantics, disparate syntactic infrastructures, levels of expressive power,
varieties of value networks, cost structures, legacy inertia, and even the
politics of information systems.
Is DC-MES the last word in metadata? Certainly not. Will it be the starting
place for every metadata application? No. However, to the extent that DC-MES
meets the the core functional requirements of new applications, we hope that
such applications will adopt the core set of elements, *and* will work in
the spirit of open standards exemplified in the DCMI to add additional
functionality in a modular, extensible way.
stu
Stuart Weibel
-------------------------
Senior Research Scientist
OCLC Office of Research
Director, Dublin Core Metadata Initiative
[log in to unmask]
http://purl.org/net/weibel
+1.614,764.6081 (voice)
+1.614.764.2344
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|