Andy,
Some comments on your Dublin Core in XML Guidelines.
I think this is a really welcome document. I think there are a lot of
people creating DC in XML rather than RDF/XML and that some
guidelines are necessary.
I don't agree with suggestions about putting <rdf:RDF> round the
outside. This looks like fairly meaningless and useless syntax to
people who don't know about RDF and they are likely to
immediately stop reading. I've already heard reactions to the 'DC
Simple in XML' document that it is really about DC in RDF and so
will be ignored. Outside the small DC community, it is hard enough
to 'sell' DC (it's getting a lot of stick these days). The reaction to a
mention of RDF is 'oh no, not yet another acronym - why do I need
to know about it'. XML is more widely known, or at least heard of,
and more people are using it. So I think that insisting DC should be
encoded in RDF could put people off using DC, the simplicity of
which is one of its strengths.
Personally, I haven't yet found a convinving reason why I should be
using RDF. I believe that OAi are using XML, and the CIMI DC DTD
required by Z39.50 Bath Profile is XML.
I think it's unfortunate that some guidelines have not appeared
before now, particularly for encoding qualified DC. I am a bit
concerned about existing metadata and applications which do not
conform to the guidelines, and stuff which has been published. I
wonder if some advice should be included - though I don't know
what, I'd like some advice myself!
Comments on the content of the document:
General:
The sections and the numbered points are a bit mixed up - it looks
odd. Perhaps you need to say that you are making 8 points
throughout the document.
1. Use schemas rather than DTDs.
I'm not really convinced about this. If you are going to make this statement
it requires a bit more justification. The word 'should' seems a bit strong. I don't
believe DTDs are dead yet. Perhaps this is because I've come to XML
via SGML. DTDs provide a rigorous specification and parsing of the XML
document - maybe schemas do as well, I don't have any experience of them.
For DC, the addition of data-typing is not really a reqiurement. A lot of exisiting
software being used to process XML requires a DTD (eg. Cheshire) because
it was developed for SGML. So although you may advise use of an XML
schema and possibly provide a 'standard' DC schema, I think that a DC XML
DTD should also be provided.
2. Container element names.
Are you intending to fix on one name for the final document, or to
leave in this note with a selection of choices? The CIMI DTD uses
<dc-record> (and then has no 'dc:' prefixes to the elelemtn names).
I don't like the name <description>. I think this would cause too
much confusion with the <dc:description> element. I assume this
'description' has come from RDF. 'Description' is rather an
overloaded word which to me tends to mean just a natural language
description. An XML document is more rigurously defined - I would
think of it more as a specification or a definition.
Abstract Model (both DC and QDC):
As above, I have reservations about the word 'description'.
'A property is an attribute' and 'each property must be one of the 15
DC elements', ie an XML element. This is OK, but I wonder about
confusion with an XML attribute, which is how you've encoded
'scheme' after point 7. Maybe there should be some comment
about the different uses of the word 'attribute'.
For QDC: 'Each value is either a literal string or a URI'. Isn't a URI
an instance of a literal string? I think the value is a literal which has
to be interpreted accoring to the scheme. So if scheme=URI, value
is eg http://www.ukoln.ac.uk and if scheme=DDC, value is eg 020.
I think a URI needs the scheme=URI otherwise the note about
simple DC applies.
Short example - Simple DC:
I would be inclined to split the <dc:subject> value up into separate
instances of the element, eg.
<dc:subject>conferences</dc:subject>
<dc:subject>lectures</dc:subject>
Subsequent processing always seems easier after you've done
this. But maybe there are some existing guidelines about this
which I've missed.
6. Nested element refinements:
I'm not sure about this - I'm still thinking about it. I've so far been
using
<dc:date refine="available">2002-06</dc:date>
But looking at your subsequent explanation about 'duration',
perhaps I agree. This is where I'm worried about exisiting metadata.
I think dumb-down would be simpler with the 'refine' attribute rather
than the nesting, but only for one level.
This means you can have within one metadata record:
<dc:title>My article<dc:title>
<dc:title><dct:alternative>Another title</dct:alternative></dc:title>
which doesn't look good balanced XML, though I think a DTD can
cover it. It makes me wonder if there should be a default sub-
element, eg.
<dc:title><dct:main>My article</dct:main></dct:title>
but this is removing simplicity from DC.
You should explain the 'dct:' prefix. It took me a while to realise it
is a dct (terms) namespace. This means I haven't yet read the
namespace policy document, but I doubt if the average reader will
have either.
Can you include some guidelines on case for element refinements
where they are several words, eg isPartOf. Does the lower case
apply to everything? I think isPartOf is better than ispartof.
7. Scheme
Some guidelines on the scheme name would be good. The DC
qualifiers document gives each scheme a 'name' and a 'label'. In
some cases I'm not too sure which to use. Is it:
scheme="W3CDTF" or scheme="W3C-DTF", and
scheme="DCMIType" or scheme="DCMI Type Vocabulary" (the
first is the 'name', the 2nd the 'label').
8. language
I assume this language attribute is optional, ie 'should' means how
to encode it, not that it must be present.
Short example (QDC)
It would be good to include a repeated element with different
refinements here (eg 2 dates) or with and without a refinement (eg.
the title eg above).
I can send you (but not the list - I don't want to swamp everyone)
some examples of XML I've created in various projects, if these
would be useful. Some include mixed metadata schemes (DC with
local). Though I can't guarantee they are right!
Hope this helps,
Best wishes,
Ann
--------------------------------------------------------------------------
Mrs. Ann Apps. Senior Analyst - Research & Development, MIMAS,
University of Manchester, Oxford Road, Manchester, M13 9PL, UK
Tel: +44 (0) 161 275 6039 Fax: +44 (0) 0161 275 6040
Email: [log in to unmask] WWW: http://epub.mimas.ac.uk/ann.html
--------------------------------------------------------------------------
|
