Dear Carl,
The only way that you can define an XML Schema which will force people to only
use dumb-downable sub-elements is to specify the exact list/names of
sub-elements permitted - and to a large extent, this defeats the purpose of
application profiles.
For the moment, I advocate your second proposal - DCMI defines a base schema
which provides a list of dc elements which can contain "any well-formed xml".
OAI can then import these types and define its simple list by restricting the
element types to strings.
It may be that this approach will severely compromise any hope of
interoperability - in which case, in time we can narrow the type definitions.
Given the time its taken to get the RDF Schema representation of DCMES right
(years?), I don't think its wise for DCMI to define a restrictive XML Schema
specification in such a short time frame (10 days?)
jane
>
> Now to take off my objective hat, let me state some opinions:
>
> This issue revives all concerns about dumb-down ability. I think that Jane and others (e.g., Dan Matei [1]) are correct in stating that many communities will want to do more than simple strings. Dan Matei [1] for example wants to create sub-structure within the tree node defined by a dc element. Dan claims that "Of course, the second form could fallback to the first", i.e., it is possible to reduce the sub-tree in which the "structured value" is embedded to a dumb-down unqualified form. In his case that is indeed true - but the schema says nothing about the restrictions on that content model and permits things like:
>
> <dc:creator>
> <foo:firstName>Carl</firstName>
> <foo:lastName>Lagoze</lastName>
> <foo:affiliation>Cornell University</affiliatioin>
> </dc:creator>
>
> which according to Tom Baker's dumb-down grammar [2] (with which I agree) claims that Cornell University is the creator of the resource and not an attribute of the entity Carl Lagoze (who is the creator of the resource).
>
> The RDF expression of dc suggested by [3] a solution to this in RDF space making use of rdf primitives such as rdf and rdfs primitives such as type, label, isDefinedBy and type - and a corresponding algorithm for extracting the "approproprate literal" for those applications that don't know how to traverse an arbitrary sub-graph.
>
> As of yet, we don't have a model for doing this in non-RDF xml, leaving us with several alternatives:
>
> 1. We (DCMI) try to not put the cart before the horse (which it appears that OAI may have done by pushing a "simple dc XML schema") and go on a longer track to get this modeling right in XML. (OAI could continue as before to have its own simple dc xml schema without importing anything from dcmi).
> 2. We (DCMI) go ahead and define a base xml schema that simply states the dc terms and provides a base value of "any well-formed xml" - this is what I think Jane is advocating. In this case we could provide the basis for some later modeling on how to restrict these trees so that they are dumb-downable (or decide not to enforce this at all in a schema).
> 3. We (DCMI) make an easy stab at this by providing a base schema that a) allows a value of any xml subtree but b) requires a text value resulting in xml like the following:
>
> <?xml version="1.0" encoding="UTF-8"?>
> <creator>
> <firstName>Carl</firstName>
> <lastName>Lagoze</lastName>
> <affiliation>Cornell University</affiliation>Carl Lagoze</creator>
>
> Where the text string is the "dumb-down" value. This essentially copies what the RDF construct is doing.
>
> I'm thinking that the third is the best alternative is the best and I believe possible. Now if the xml schema wonks (Jane, Pete, Naomi?) can present how to do this, we maybe can proceed.
>
> I hope I've gotten this all right and apologies in advance if I've mis-stated anything.
>
> Carl
>
> [1] http://www.jiscmail.ac.uk/cgi-bin/wa.exe?A2=ind0203&L=dc-architecture&F=&S=&P=3896
> [2] http://www.dlib.org/dlib/october00/baker/10baker.html
> [3] http://dublincore.org/documents/2001/11/30/dcq-rdf-xml/
>
> > -----Original Message-----
> > From: Naomi Dushay
> > Sent: Wednesday, March 06, 2002 1:43 PM
> > To: [log in to unmask]
> > Subject: Re: Public Comment on DC-simple XML Schema declaration within
> > OAI
> >
> >
> > > But even with these one-per-element types/models I'm still
> > > not sure how
> > > to achieve the sort of application-specific "tightening" of
> > > the content
> > > model which Carl suggested though. e.g. if an app wants to
> > tighten its
> > > own content model for dc:date so that it validates as a date
> > > rather than
> > > only to the loose base model, or if OAI wants all element
> > > content to be
> > > strings....
> >
> > My XMLSchema knowledge is far from perfect, but have you
> > investigated the notion of abstract types? That is,
> >
> > <xsd:complexType name=dateModel abstract="true">
> > stuff about dateModels pertinent to the generic cases
> > </xsd:complexType>
> >
> >
> > Perhaps this approach is also flawed -- I don't think you can
> > instantiate an element to an abstract type. BUT it does
> > allow for the notion of "sub-classing", which is what we
> > really want to do: we want to be able to view information as
> > DC:date and as myDC:date at the same time ...
> >
> > - Naomi Dushay
> >
|