Dear Carl, Rachel,
I agree with Carl's assertion that neither approach is the only correct one.
In some situations, there is going to be clear overlap between metadata terms
from different domains, so duplication within 'application profiles' doesn't
make sense and dynamic mapping based on simple substitution should be employed.
However my recent experience with mapping MPEG-7 to DC has shown that in
certain situations the mapping may be so ugly, its simply easier to combine a
top-level DC description for simple resource discovery purposes with the other
domain-specific metadata description (e.g. an MPEG-7 description for more
complex multimedia content management). There's a paper on this work which was
presented at the last MPEG meeting in Beijing: "MPEG-7 Harmonization with
Dublin Core: Current Status and Concerns":
http://archive.dstc.edu.au/RDU/staff/jane-hunter/m6160.zip
So rather than trying to perform this complex mapping dynamically using the
limited capabilities of XSLT, it makes more sense to create a new XML Schema
which imports elements from both namespaces to create a new schema. As Dan
Brickley has pointed out to me, the other advantage of this approach is that it
decouples the semantic constraints in the vocabulary definitions (in the
imported namespaces) from my own local structural, datatyping and cardinality
constraints e.g.
<myschema ...
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:mpeg7="http://www.mpeg.org/MPEG7/2000/"/>
<element ref="dc:title" minOccurs="1" maxOccurs="2">
<element ref="dc:creator" minOccurs="1" maxOccurs="3">
...
<element ref="mpeg7:CreationMetaInformationDS" minOccurs="1"
maxOccurs="1"/>
<element ref="mpeg7:UsageMetaInformationDS" minOccurs="0"
maxOccurs="unbounded"/>
</myschema>
The other point I want to make with this example is that given schemas such as
the one above, I really don't understand the necessity for calling it an
'application profile'. Given people's tendency to want to do their own thing,
there could potentially be an infinite number of these schemas and as long as
the schema definition which goes with a particular description is provided
somewhere then interoperability is provided, without registering it as an
'application profile'. Unless I'm missing the point of application profiles?
jane
+----------------------------------+---------------------------------------+
| Dr Jane Hunter | Senior Research Scientist |
| DSTC Pty Ltd | Distributed Systems Technology CRC |
| Level 7, General Purpose South | Tel : +61 7 3365 4310 |
| The University of Queensland | Fax : +61 7 3365 4311 |
| Queensland 4072, Australia | Email : [log in to unmask] |
+----------------------------------+---------------------------------------+
> 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
>
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|