On Fri, 8 Mar 2002, Carl Lagoze wrote:

> My omission probably comes from my fuzziness (and the general overall
> fuzziness) about relations between namespaces, schema documents, and
> instance documents.  We all agree that there should be one namespace
> (http://purl.org/dc/elements/1.1/) for the dc element set, which is
> independent of schema representation.

Yes (though new elements such as audience will go into the dcterms
namespace).

> I was then going on the assumption that there should be one (and only
> one) xml schema document for this namespace; e.g. one that provided
> the breadth of expression requested by the qualification crowd but
> could be restricted in deriving schema by the simple crowd.  Thus the
> entire chain of discussion that ran through yesterday.
>
> If I am not mistaken, the position advocated by you is that we have
> two (or even more) xml schema for the dc element namespace; one for
> simple dc (just the 15 and their string values) and one for qualified
> (the model for which still needs to be developed).  This may indeed be
> a workable route out of this dilemma to accommodate the different
> needs of these crowds.

Yes, that is what I'm suggesting.

> Somehow, though, it pushes against my basic software engineering
> principles.  If we think of the 15 dc elements as primitive abstract
> classes, which may then be restricted to their simple form or
> specified in some richer form, it seems that there should be one xml
> schema providing that base.  I say this recognizing that such
> engineering "purity" sometimes needs to be put aside to get a job done
> in a reasonable manner.

I agree that it's not ideal - but I also don't want to sit around for the
next 6 months while we try and agree how to do fairly complex things with
XML schemas and in the meantime continue to provide very little help to
people who actually have quite simple requirements.

> Just as an aside, I note that your document at
> http://www.ukoln.ac.uk/metadata/dcmi/dc-xml-guidelines/ (great
> document!!) does specify a model where qualified DC is still
> restricted to string values.  It is then your real intention that the
> qualified DC model is more restrictive than that proposed for RDF by
> Roland, etc. in
> http://dublincore.org/documents/2001/11/30/dcq-rdf-xml/, which
> proposes intermixing of simple appropriate literals with arbitrarily
> complex other information (sub-graphs).  I ask this with some
> hesitation because as you know I have serious issues the entire highly
> qualified world of Dublin Core.

I think that our problem is that we don't have a shared understanding of
what 'simple dc' and 'qualified dc' mean.  I've put forward my ideas in
that document.  Nobody has commented on them.  Frankly, I was suprised at
this, cos I was expecting my descriptions of the models underlying simple
dc and qualified dc to be at least a little contentious.

To my mind, putting complex, structured, values within DC elements is
neither 'simple DC' nor 'qualified DC'.  It is something else, which I
think might be refered to as 'complex DC' - but on the other hand, imagine
we are talking about mixing IEEE LOM and qualified DC in fairly complex
way.  Why is that 'complex DC' any more than it is 'complex IEE LOM' ??

> Carl
>
> > -----Original Message-----
> > From: Andy Powell [mailto:[log in to unmask]]
> > Sent: Friday, March 08, 2002 2:12 AM
> > To: [log in to unmask]
> > Subject: Re: Public Comment on DC-simple XML Schema declaration within
> > OAI
> >
> >
> > On Thu, 7 Mar 2002, Carl Lagoze wrote:
> >
> > > 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:
> >
> > Carl,
> > I'm replying to your earlier message (but I've seen all the subsequent
> > ones and hope I understand them!).
> >
> > Your analysis above misses a forth possibility - that we stick with a
> > simple DC schema (as we originally proposed) that limits
> > element values to
> > simple strings.
> >
> > I stand by the assertion in section 4.1 of
> >
> >   http://www.ukoln.ac.uk/metadata/dcmi/dc-xml-guidelines/
> >
> > that in simple DC "each value [of a property] is a literal string".
> >
> > The desire to embed more complex structured information into
> > a DC element
> > value is fine... but it is *not* 'simple DC' (IMHO).
> >
> > The XML schema under discussion is explicitly an XML schema
> > for 'simple
> > DC'.  Therefore, it would be inappropriate for the schema to allow
> > anything other than strings as element values.  Therefore we
> > should revert
> > to the originally proposed XML schema.
> >
> > Here are two arguments to support this position:
> >
> > 1) If the abstract model for 'simple DC' that we proposed
> > above is wrong,
> > i.e. if the simple DC model allows element values that are
> > more complex
> > than literal strings, then we can *not* implement 'simple DC'
> > in HTML meta
> > tags.
> >
> > 2) If the abstract model for 'simple DC' allows complex element values
> > then, as has been discussed on the list, we have to be able
> > to dumb those
> > values down.  What are we dumbing down to?  'Really simple DC'?  'Dumb
> > DC'?  'Dumber DC'!?  Surely 'simple DC' is the bottom line in terms of
> > dumbing-down?
> >
> > In conclusion, we should have an XML schema for 'simple DC'
> > that restricts
> > element values to be of type 'string'.  We should get that
> > schema in place
> > now so that people (including the OAI) can start using it.
> > We should move
> > forward with discussions about 'non-simple DC' separately -
> > and part of
> > those discussions will be about whether we are discussing
> > 'complex DC' or
> > 'qualified DC' or something else!  But it won't be 'simple DC'!
> >
> > Andy
> > --
> > Distributed Systems, UKOLN, University of Bath, Bath, BA2 7AY, UK
> > http://www.ukoln.ac.uk/ukoln/staff/a.powell       +44 1225 383933
> > Resource Discovery Network http://www.rdn.ac.uk/
> >
>

Andy
--
Distributed Systems, UKOLN, University of Bath, Bath, BA2 7AY, UK
http://www.ukoln.ac.uk/ukoln/staff/a.powell       +44 1225 383933
Resource Discovery Network http://www.rdn.ac.uk/