On Fri, 20 Sep 1996, John Kunze wrote:
> 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.

Gosh; this must be one of the greatest examples of the documentation
changing the product and completely out of the blue as well.  Crumbs. 
Therefore this email is going to have to be quite long as well so that I
can cover all the areas that concern me; hit delete now if you're not
interested in reading my long rambling drivel... :-)

> eg, isn't it time to start _requiring_ some elements?

No IMHO.  I'd like DC to continue to be nice and loose so that it can be 
used in situations where you don't know (and maybe can't know) some of 
the element values.  Like not knowing who the author of a web page is or 
even what its real title is (yep, there are untitled documents).  I know 
for a fact that if we required, say, Author lots of the resource templates 
that subject services that we supply our software to would suddenly cease 
to be DC compliant.  And that would be a bummer.

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

I'm not too fussed about this, but I guess that the GIS people (and 
related types) might be a bit pissed at loosing this element.  Having one 
element to cover spatial and temporal information didn't seem to much of 
an overhead to me.

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

Fine by me.  Its just a name (but lets be consistent on what we call 
things _before_ we all start showing our wares to Joe Public; if 
everybody likes this, I'll change my documents accordingly).

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

Why not subsume author as well?  An author is just another contributor 
after all.

> 4. subsumed Source into Relation
> natural fits, less is more

Fine.
 
> 6. eliminated the qualifiers "type" and "identfier"; added "flags" qualifier
>    - type (hopeless, never defined)

Not keen on loosing Type; Paul, Dave, myself and some of the other meta2
bods seemed to be converging on using Scheme to indicate that an element
value conforms to some known external representation and the Type
sub-element for dealing with DC specific element values.  That seemed to 
be quite popular judging from the email I got about it.

>    - identifier (confusing, functionality easily subsumed

Yep, I'd come to that conclusion as well.

> 2.1. Example: Stand-Alone Metadata
> 
> The first example of a metadata record is contained in a computer file by
> itself. It describes a photograph in another file that has a location given
> by a Uniform Resource Locator (URL) [2]. The entire record file looks like
> this.
> 
>         <META name="dc.Title" content="Kita Yama (Japan)">
>         <META name="dc.Author" content="Kertesz, Andre">
>         <META name="dc.Date" content="1968">
>         <META name="dc.Type" content="e/photograph">
>         <META name="dc.Form" content="GIF">
>         <META name="dc.Resource" content="http://foo.bar.zaf/kertesz/kyama">

Err, if its in a file by itself (ie not embedded in HTML), shouldn't it 
be using the SGML DTD that the Lou et al came up with just after the 
Warwick meeting?  The use of the META element is an HTML thing and is a 
bit pointless for a standalone file.

> Another point of interest is the Resource (dc.Resource) Content, which
> normally contains a URL showing the document's Web address (as in the
> previous example). In this case, the characters ``$File'' probably mean that
> the Web site has been set up cleverly to replace those characters with a URL
> for the current location before the indexing program comes to collect
> metadata. This is a hypothetical site-specific solution to a common problem
> of maintaining metadata when the file location changes, and support for such
> a mechanism is outside the scope of this guide.

That's a kludgy hack; I don't think its really appropriate for a DC user 
guide.

>         <META name="dc.Author; Role=composer"
>               content="Honauer, Leontzi; Schobert, Johann">
> [...]
>         <META name="dc.Resource; Scheme=LCCN"
>               content="M219.H65P">
> [...]
>         <META name="dc.Resource; Scheme=none"
>               content="UCB Music Lib., Case X">

Agghhh, I hope that isn't supposed to be <META> elements for embedding in 
HTML 2.0 documents.  I thought we'd got through the META element 
formatting problem in a way that was valid for the HTML 2.0 DTD; those 
META elements above ARE NOT valid.  Please can we have our valid format back:

  <META NAME="DC.author" 
    CONTENT="(role=composer) Honauer, Leontzi; Schobert, Johann">

I know I'm anal about this but I think that it's very important to make sure 
that we build on the standards we've got, not break them.

> Creators of metadata, also known as ``metaloguers'',

Are they?  First time I've head of ``metaloguers'' and Alta Vista had 
never heard of the word either (Alta Vista is, as we all know, replacing 
the OED as the English dictionary of choice these days :-) ).  We're not 
making up new words are we? :-) :-)

> 3.1. Author (au, 1)
> 
> Authors may be names of people (default) or organizations (flags=-p). 

I like the idea of flagging organizational names but isn't "flags=-p" a
tad cryptic?  Its fine for my programs but maybe not something we'd want
Joe Punter to be exposed to.  Could we at least have optional more verbose
versions?  I would think that this is quite important considering the
number of times people have said that they'd like DC to be human readable.

Also we need some way of specifying ordering of authors (and maybe the 
other contributors?).

> 3.2. Date (da, 5)
> [...]
> This format provides software with an unambiguous date
> that is simple to convert to a variety of display formats (e.g., 6 May 1995)
> and easily ordered with respect to other dates (e.g., for range checking or
> chronological sorting).

One big thing missing in this date format is a time zone.  Are you 
assuming that all dates will be in UTC and the browser/robot/whatever is 
responsible for conversions to/from local time zones.  If so, then this 
should be explicitly stated.

Can I also suggest additional roles (as they appear in your document) of 
ValidFrom and ValidTo?  ValidFrom is the date from which the resource is 
valid and ValidTo is the date after which the resource is not longer 
valid.  Handy for resources with known temporal characteristics (eg: HTML 
adverts for the latest movies that won't be on the server six months from 
now but whose metadata might still be swishing about inside some big 
indexers).

> 3.3. Form (fm, 6)
> 
> Default Qualifiers: role=best1.0, scheme=rmv.
> Some Content designations from the RMV scheme (which borrows heavily from
> MIME [8] XXX) are listed here.

Why not just use MIME?  What's the need for RMV (is it a library standard
that I don't know about or is it a DC special)?  I think scheme=MIME (or
scheme=IMT if you're being all modern).  At least MIME already has a
running registry and we wouldn't need to duplicate effort.  Or is RMV a
completely fixed, non-expandable list of resource types? 

> 3.4. Resource (rs, 8)
> 
> Some creators of metadata will wish to maintain links by automatic processes
> that make it possible to move files around without changing the URIs
> embedded in metadata. By convention, a Resource link Content of ``dummy''
> may be used as a signal to those processes to replace the Content with a
> correct URI.

Er, surely they'll still need an identifier of some sort in order to know 
what the real URL (or ISSN or SICI or URN or whatever) is?  This seems 
like a bit of a hack to me again; its something that should be internal 
to the local processing software and not something we need to specify in 
a global "on-the-wire" guide.

> For certain resources, such as very small documents, it may be useful to
> include the entire document in the descriptive record. In this case, use the
> ``flags=-l'' Qualifier to indicate that the resource identified is available
> immediately (or inline) as the Resource element Content. For example, here
> is a tiny poem represented inside one its own metadata elements:

Heh, I can see an option for infinite recursion here (eg: an HTML 2.0 
document containing its metadata which contains an HTML 2.0 document 
which contains its metadata which etc, etc, etc) :-)

> 3.5. Language (la, 7)
> 
> Language: The human or computer language in which the intellectual content
> is expressed.

I'd suggest using ISO 639 as the default Scheme for this element and then 
allowing other Schemes to deal with languages (such as computer languages 
and non-verbal languages such as BSL).  Referencing an externally 
maintained, well known standard directly seems to be a much easier course of 
action than creating this new RMV scheme sub-element type from a variety 
of sources.  Why make more work for ourselves?

> 3.7. Contributor (co, 9)
> 
> Contributor: A person or agency, other than Author, who has made noteworthy
> secondary contributions to the resource.

Again, I'd say that we could get author in there as well if we're after 
lopping off elements.

> 4. Basic Principles of Descriptive Elements
>
> In summary, an element definition looks like
> 
>         <META name="dc.NAME; QUALIFIER=VALUE" content="CONTENT">
> where the ``; QUALIFIER=VALUE'' part is optional and may be repeated. Spaces
> around the `;' are optional.

Once again I'll plead for:

  <META NAME="dc.ElementName" CONTENT="(sub-element=sevalue) ElementValue">

for use in HTML 2.0 documents and the existing SGML DTD for stand alone 
Dublin Core records.

> Any metadata element may be omitted or repeated. As a shorthand for repeated
> elements, one element can share its Name part (including Qualifiers, if any)
> with a second element by appending a `;' (semi- colon) and the Content of
> the second to the Content of the first. So the first two lines below are
> equivalent to the third line.
> 
>         <META name="dc.Author" content="Marx, K">
>         <META name="dc.Author" content="Engels, F">
>         <META name="dc.Author" content="Marx, K; Engels, F">

> To repeat elements with different Qualifiers, list each element definition
> separately; the shorthand cannot be used. Use a backslash, as in ``\;'', if
> you want to include a literal semi-colon in the Content. To include a
> literal double-quote (`"') in this metadata notation, write it as %22 [XXX].

Can we have uniform escaping please?  Otherwise, how would you encode the 
literal %22 (not the encoded form of `"')?

> 4.4. Kinds of Element Name Qualifiers

As a quick aside, the preceeding sections would make more sense if 
Section 4.3 and this section preceeded them.  I'm reading this linearly 
and I was left floundering earlier on as to what the sub-element "flags=l" 
meant in the Resource element.  This section clears that up, but it would 
make the document easier to read if the terminology came before the 
DC Element descriptions.

> Element Qualifier: flags (fl, 32)
> 
>      Flag=g
>           The element Content specifies a geospatial region associated with
>           the resource being described. By default, elements are not
>           associated with geospatial regions. For example, here's a record
>           for a map that has a conventional as well as a second title that
>           is rather more useful for searching than for display (to the
>           average searcher).
> 
>                   <META name="dc.Title" content="Great Barrier Reef Marine Park">
>                   <META name="dc.Title; flags=g; scheme=FGDC"
>                           content="E1800000, W1800000, N900000, S900000">
>                   <META name="dc.Date" content="19960912">
>                   <META name="dc.Type" content="e/map">

I think this is the best example of why the DC.coverage element is 
needed. :-)

> 6. Non-Core Metadata and Creating Your Own Element Names
> 
> Experimental metadata terms are either Shared Experimental or Private
> Experimental. Private Experimental terms may be created and entered into the
> RMV database at will by any organization that wishes to sponsor them. The
> terms all start with ``x.ORG.'', where ORG is replaced by the organization's
> abbreviation. For example, ``x.ucsf.library'' and ``x.ucsf.cafeteria'' might
> be campus locations sponsored by UCSF. When a Private term has achieved
> sufficient community acceptance, it becomes Shared Experimental, in which
> case it loses the organization abbreviation, as in ``x.library'' and
> ``x.cafeteria''.

This is a cool expansion mechanism.  Might want also to mention Warwick 
Framework as another means of adding additional metadata packages without 
needing to fiddle with DC?

Sorry if this email was a bit long and sounded a bit negative but the 
User Guide did contain an awful lot of changes from what we currently 
know and love as DC and I felt obliged to comment.  Shoot me now. :-)

Tatty bye,

Jim'll

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Jon "Jim'll" Knight, Researcher, Sysop and General Dogsbody, Dept. Computer
Studies, Loughborough University of Technology, Leics., ENGLAND.  LE11 3TU.
* I've found I now dream in Perl.  More worryingly, I enjoy those dreams. *