Rachel,
Thanks for circulating your position paper on applications profiles [1].
I read it with interest and think that it raises a number of interesting
issues that need to be raised in the context of DCMI. Put together with
Tom Baker's grammar paper [2] and my simplicity and complexity paper [3]
it opens up an interesting context for conversations. To start the ball
rolling here is my perception of areas of agreement and possible
disagreement.....
No surprise that we all agree that DCES is not a "complete metadata
solution". Rather, as formulated since DC2 at Warwick, DCES defines one
set of metadata semantics that will coexist with other role, purpose,
community, etc. metadata 'packages'.
If I read your proposal correctly, my impression is that you formulate a
metadata architecture whereby DC elements (e.g., creator) will be
intermixed with other community/application specific elements (from
separate namespaces). Such intermixing implies a 'building block'
approach to creating metadata descriptions. While such an approach
might seem appealing I find it possibly inconsistent with some of the
thinking about DC 'statements' as described in Tom's paper [2].
As stated by Tom in [2], DCES is essentially a metadata pidgin that can
express sets of statements of quite limited nature - i.e. the
limitations of qualification and the notion of an 'appropriate literal'.
Given this, the use of DC elements in an application profilie would be
rather restrictive. For example, I could use DC:CREATOR element for
only the purpose of providing a name. However, as is well know many
communities wish to describe the entities that are included in DCES
semantics in a much richer fashion; e.g., the many discussion we have
had about agent attributes and the agent core issues. I'm confused then
about how one would use applications profiles in such a context. Would
I have parallel elements using something like DC:CREATOR for a simple
name and than elements from another namespace for a more complex creator
description (e.g., the sort of thing that vcard does) that would
probably also include and duplicate the creator name? The creator
element is not the only one where this problem arises.The potential for
such parallelism and overlap exists with other DC elements, since many
communities want more complex descriptions for many of the entities
implied by DC elements. It appears that rather than ending up with nice
neat building blocks as shown in your position paper, we could end up
with some messy descriptions with elements from different namespaces
that overlap each other and duplicate bits of information.
Perhaps a more workable solution is not to think of DCES as one building
block in putting together a metadata description, but to think of it
(and other metadata descriptions) as views or perspectives into more
complex descriptive frameworks. The DCES view could then co-exist with
other views that conform to different application and community specific
needs. With developing technologies such as SOAP [4] or in a
architecture such as FEDORA [5] that we've created at Cornell, it would
be possible to for clients to request a metadata view that matched the
clients needs and for the such view to be derived from some more
descriptive framework (such as the event based model stated in [3] and
[6]). (This corresponds to Tom Baker's assertion that DCES is not
necessarily a record format but 'pidgin speak' for richer descriptive
semantics). Such a model would allow DCES to fulfill its very important
role as a model for interchange of simple cross-domain resource
discovery metadata, without trying to mix it in perhaps messy ways with
more complex descriptive semantics.
Again, thanks for the position paper and its great to see us in DCMI
start to move beyond discussions of just the 15 elements. I make no
assertion here that your solution is 'wrong' and mine is 'right'. Both
have issues that need to be discussed and I look forward to community
moving forward on these.
Carl
[1] http://www.mailbase.ac.uk/lists/dc-general/2000-08/0000.html
[2] http://www.mailbase.ac.uk/lists/dc-general/2000-08/0016.html
[3] http://www.mailbase.ac.uk/lists/dc-general/2000-08/0018.html
[4] http://www.develop.com/soap/
[5] http://www.cs.cornell.edu/cdlrg/FEDORA.html
[6]
http://www.ncstrl.org/Dienst/UI/1.0/Display/ncstrl.cornell/TR2000-1800
------------------------------------------------------------------------
----
Carl Lagoze, Digital Library Scientist
Department of Computer Science, Cornell University
Ithaca, NY 14853 USA
Phone: +1-607-255-6046
FAX: +1-607-255-4428
E-Mail: [log in to unmask]
WWW: http://www.cs.cornell.edu/lagoze/lagoze.html
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
