Hi Jane,
Maybe I mistakenly implied that but...
What I meant to say is that:
1. Do not spec an exact list of sub-elements. Allow that to be open territory.
2. Mandate in the schema that each element have a dumb-down value. Sigge's earlier mail stated this with the tag <simpleValue> but I don't think that this syntactic sugar is actually necessary.
Does this make sense or am I missing something?
Carl
> -----Original Message-----
> From: Jane Hunter [mailto:[log in to unmask]]
> Sent: Thursday, March 07, 2002 8:04 AM
> To: [log in to unmask]
> Subject: Re: Public Comment on DC-simple XML Schema declaration within
> OAI
>
>
> 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-archi
tecture&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
> >
|