> As promised more than once to this list, the Dublin Core metadata User
> Guide subgroup is ready to release a draft document suitable for review
> by the meta2 list.  The draft is at http://www.ckm.ucsf.edu/meta/mguide3.html
> or, if you prefer, you can read the complete text included in this message.
> 
> There have been big changes.  If you examined the Dublin Core minutely,
> as the User Guide group did, you will have noticed that the patient
> arrived at the Warwick workshop in critical condition.  It had swallowed
> elements without chewing, was making incoherent statements, repeating
> itself, suffering from lack of structure, and hemorrhaging credibility.

"Haemmorrhaging credibility" is a little strong, isn't it...?  ;-)  OK, 
so Dublin Core wasn't perfect, but what is...?

This new guide DOES appear to make some rational changes to the 
existing DC framework, but it also appears to introduce change for 
change's sake in more than one place, and to stretch the <META> tag a 
little too far in others... I'm also a little surprised at how little 
attention appears to be paid to some of the recent 
discussions over such issues as the SCHEME | TYPE dichotomy. 
On the whole, I pretty much agree with the comments already made by Jon 
Knight and Terry Allen, but here goes with some comments of my own...
 
> The User Guide group is happy to announce that after significant surgery,
> a healthier Dublin Core has been taken off the critical list, its condition
> downgraded to serious.  We managed to gut, clear, strengthen, and sharpen.
> 13 elements have been reduced to 10; plus a net reduction of one qualifier.
> Elements and qualifiers have short, long, and numeric names.

I've a feeling that these multiple names for the same element (short, 
long and numeric) may lead to confusion, rather than anything else... 
What's wrong with just the long names... they're hardly HUGE, after 
all...!


> There's a great deal of work to be done, especially w.r.t. controlled
> vocabularies, further simplification, and further restriction of the
> problem space (eg, isn't it time to start _requiring_ some elements?)

No. DEFINITELY not. One of DC's greatest strengths is its very 
flexibility...


> Some changes proposed for Dublin Core
> -------------------------------------
> 1. eliminated Coverage 
> too specialized, some functions covered by flags qualifier, less is more

As someone concerned with both space and time on a daily basis, I was 
initially not keen to see this element removed. However, thinking 
about it, the Coverage element is actually too vague to be much use 
in REALLY describing space and time (I think I've used it about 
once)...

Be interested to see if those currently sunning themselves in Ohio 
explore the relationship of this element to image metadata, or come 
down in favour of a (possibly more useful) Warwick Framework package 
to embed DIF and FGDC instead...

Still... despite being far from comprehensive, it's nice to have an 
element that allows a crude description of space/time when you need 
it... All in all, I say keep it. If nothing else, it gives the user 
an awareness that DC can deal with more than poems...!   ;-)

> 2. renamed ObjectType to Type
> less jargon, why qualify this element (e.g., no ObjectAuthor?)

I agree with Terry Allen here... Type is just too vague, and could 
mean almost anything. Author is far less ambiguous...

> 3. new element Contributor subsumes OtherAgent and Publisher
> less jargon, fewer similar elements

OK, I suppose...

> 6. eliminated the qualifiers "type" and "identfier"; added "flags" qualifier
>    - type (hopeless, never defined)
>    - identifier (confusing, functionality easily subsumed
>    - flags (succinct set of element hints)

NO! A lot of work has been done recently on resolving SCHEMEs and 
TYPEs, and I thought we were actually getting somewhere... A SCHEME 
is an external naming system (ISO639 codes for languages etc) and a 
TYPE is an internal Dublin Core subdivision of a DC element.

TYPE is also (surely) a more intuitive label than FLAG...

DC.Author (TYPE=affiliation) University of Newcastle

surely makes more sense than

DC.Author (FLAG=affiliation) University of Newcastle

"flags (succinct set of element hints)" -- Yes, perhaps a little TOO 
succinct! Those single letter flags outlined later on are hardly 
intuitive, now are they...?!

> 2.1. Example: Stand-alone Metadata

Eh? I thought we'd all pretty much decided that where metadata was 
about the file containing it, we would use the <META> tag, but there 
seems absolutely no point in using the <META> tag to provide metadata 
about ANOTHER file entirely.

Several people have already explored this (Lou Burnard and gang after 
Warwick, my original ADS paper, etc) and they all seemed to come down 
in favour of a totally non-<META> approach to describing other files. 

Also, this idea of e/ and p/ to denote 'electronic' and 'physical' 
forms of the resource seems unnecessarily confusing. There seems to 
be a desire to convert an existing legible coding system towards an 
increasingly codified one, where we'll all need code books to work 
out what even the simplest record is about... Let's keep it simple, 
legible, and intelligible, to both humans and machines...!

Anyway, isn't the electronic or physical (aren't electrons 
'physical'?) nature of a resource implied by DC.form and DC.resource?

3.1 Author

Other than still hating the FLAG, this idea of using -p to denote an 
organization as opposed to a personal name introduces another layer 
of gobledigook into the entry...

what was wrong with the good oldfashioned

<META NAME="DC.Author" CONTENT="(TYPE=organization) Digital Equipment Corporation">

surely it's clearer than

<META name="dc.Author;flags=-p" content="Digital Equipment Corporation">

Anyway, as Jon says, the META format suggested in this new document 
is invalid, and MOST of us have just spent the past few months 
arriving at a valid format we thought everyone was happy with!

3.2 Date

Bring back ISO31 -- all is forgiven! More seriously, though, we need 
to retain scope for schemes such as the FGDC date system, which can 
handle NEGATIVE dates, etc.

Also, what about timezones?

3.3 Form

Why not just use the existing MIME Internet Media Types?

The best1.0... best0.0 qualifier system looks horrendously complex, 
and open to almost infinite misunderstanding and misuse. Where more 
than one form exists, couldn't we just apply a (TYPE=preferred) to 
ONE of them...?

3.5 Language

I'm with Jon on this one... Use ISO639 as the default, and allow 
users to select a different SCHEME to code computer languages etc...

6. Non-Core Metadata and Creating Your Own Element Names

I like the idea of the x.ORG.element-name, but thought we'd pretty 
much agreed to keep such extras out of the appropriately named Dublin _CORE_
in order to keep it small and manageable...

Why not mention the Warwick Framework here, and suggest the creation 
of a generic Warwick Framework package to put all of these in?

Incidentally, where has the concept of wrapping all the DC elements 
in a DC package gone...?

8. References

Does the dearth of 'modern' references to Dublin Core and/or 
Warwick mean the authors haven't READ any of the current work, or 
that they've simply decided to ignore it...  ;-)

Final remarks...

Where's the <LINK> tag gone...? It was a really useful way of 
pointing to extra decoding information...

Not AT ALL keen on this Flag concept...

A lot has changed between what all the rest of us saw as Dublin Core 
and this document... It's probably going to take a while to digest 
the implications...  ;-)

We shall no doubt hear more about this as people take in what the 
document really says...

Paul

  -----------
  Paul Miller
  Graphics & GIS Advisor, University Computing Service
  University of Newcastle, Claremont Tower, Claremont Road, Newcastle 
  upon Tyne NE1 7RU.    tel (0191) 222 8212/8039, fax (0191) 222 8765

  e-mail [log in to unmask]        WWW http://www.ncl.ac.uk/~napm1/
       [log in to unmask]         http://www.ncl.ac.uk/~ngraphic/