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/