> From [log in to unmask] Fri Mar 8 12:05 MET 2002
> content-class: urn:content-classes:message
> MIME-Version: 1.0
> X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
> Thread-Topic: Re: Public Comment on DC-simple XML Schema
> declaration within OAI
> Thread-Index: AcHGcf7UJBGv5Lo1QBCLpj8A9458qwAG9aVw
> Date: Fri, 8 Mar 2002 06:05:50 -0500
> From: Carl Lagoze <[log in to unmask]>
> Subject: Re: Public Comment on DC-simple XML Schema
> declaration within OAI
> To: [log in to unmask]
> Content-Transfer-Encoding: 8bit
> X-MIME-Autoconverted: from quoted-printable to 8bit by scarlett.mathematik.Uni-Osnabrueck.DE id MAA16501
>
> Andy, Yes, you are right, I failed to mention this possibility. Given my long history of advocating for "simple dc" I'm sure that was fairly surprising! ;-)
>
> 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.
>
> 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.
>
> 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.
>
> 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.
Thanks Carl for bringing this up.
In effect it exludes the use of xml-schema-dataTyping and any mechanisms associated
with it. I'm fairly confused by this, as it was my impression from Tokyo, that support for
proper dataTyping is on the agenda.
There's not much more one could do in xml-schema bound metadata
- given such restriction - as one already can do with HTML meta-tagging.
There's one exeption to that: The xlink device - which in turn seems to
syntactically fit with the xlink rec, but seems to superimpose different
semantics to xlink constructs.
I'm also under the impression, that given the convention used there, one
might not be able to link to a "simple" dc-record (missing ID attribute).
[Can't remember a dc-xml-proposal, which has ID attributes either].
rs
> 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.
>
> 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/
> >
>
|