Hi Scott,

> As I was reading the workplan, I did wonder about one thing.
> I'm relatively new to the world of formal metadata standards,
> coming at this from an IT/database background.  I'm wondering
> about a way to capture the date the *record* was created or
> revised, as opposed to the *resource* the record describes?
> Do others worry about this?  Is this beyond the purview of
> DC-DATE or of the Dublin Core itself?

Within the DC model, this problem is addressed by considering the
metadata record itself as a resource - a second resource distinct from
the one described by the record - and then creating a second metadata
record to describe the first record. (Actually in the terms of the draft
DC Abstract Model [1] currently under discussion in the DC Architecture
WG, I should probably talk about "descriptons" rather than "records"!)

The term "administrative metadata" (or the rather ghastly
"meta-metadata" (please, no, where will it end..?!)) is sometimes used
to describe that second class of metadata record, though sometimes the
term is used more broadly to describe _any_ metadata created primarily
for the purposes of managing a resource rather than for
disclosure/discovery, not just metadata about metadata records.

It's quite possible that I would use the Dublin Core metadata
vocabularies - including the dc:date property - in both of those
records, but I don't think that's a problem.

The key is in ensuring that the representational form(s) used for the
metadata records leave no room for ambiguity as to which resource is
being described by which metadata record: how that is achieved varies
according to the application context and the syntax used for expressing
the metadata records, but typically the appropriate use of identifiers
is a critical part of that - the identifier of the ("primary") resource
is not the same as the identifier describing that resource, and I can
reference the two resources without ambiguity.

For a real-world example of this, see [2] which describes the use of DC
for admin metadata within the Resource Discovery Network (RDN) (which
uses DC metadata to describe internet resources).

So in the sense that dc:date is often used in both these descriptive
contexts, the issue _is_ within the purview of this WG, but I don't see
it as an issue that requires any particular focus in this WG. We need to
be aware that the dc:date property may be used in metadata records
describing a vast range of resources - indeed the ever increasing
vastness of that range is one of the factors that has prompted some of
the issues which are on Eric's list (BCE dates and so on)! - and that
will include the description of metadata records themselves.

But I'd suggest that any disambiguation of which resource a specific
occurrence of a dc:date property applies should be handled by
standards/rules/"good practice" specified elsewhere.

> As for the working group itself, I'm also new to these.  I
> wonder if it's worth having a mechanism for members to
> respond to queries such as "does this look OK" with something
> resembling a poll?  I don't mean that we should formally
> vote, but I'm imagining an appropriate reluctance for many
> people to write to the whole membership with "looks OK to me"
> which would get tedious in quantity.  If we had a polling
> service, we could at least get some sense that the message
> has been read and met with approval.  Obviously, those of us
> with comments or questions would put them to the membership.
> How have other groups handled this?

Speaking as the chair of another DCMI WG ;-) [3] and a member of several
others, I think the way these groups operate tends to vary according to
the people involved, the nature of the activities at hand, the volume of
discussion, and so on. In the Collection Description WG, we've tended to
operate on a fairly informal basis with the chair putting out the
occasional "Shout now if you strongly disagree" or "I'm not completely
sure we're on firm ground here, I could do with some sign from the
lurkers that we're not completely losing the plot" sort of appeal ;-)

I guess the exception is when we are finalising more formal proposals
for submission to the DCMI Usage Board, when it is a _requirement_ that
we are able to show _evidence_ of support for our proposals. See 4.2.1
of [4]. I don't think it's mandatory to have a WG vote, but it would be
one way of going about it.

Cheers

Pete
-------------
Pete Johnston  [log in to unmask]
Chair, DCMI Collection Description Working Group
http://dublincore.org/groups/collections/


[1] http://www.ukoln.ac.uk/metadata/dcmi/abstract-model/
[2] http://www.rdn.ac.uk/publications/cat-guide/admin/
[3] http://dublincore.org/groups/collections/
[4] http://dublincore.org/usage/documents/process/