As a step towards preparing for the meeting in Seattle, I was planning
to create revised drafts of

http://dublincore.org/groups/collections/dccd.html

and

http://homes.ukoln.ac.uk/~lispj/dc-cd/appprof.html

to reflect suggestions made so far that seem to have some support here
(or at least haven't been opposed/rejected) - but please shout if you
feel differently!


The changes I was planning to make are:

- add a note that a CLD should have appropriate Administrative Metadata
(metadata about the metadata record);

- add clarification that free text attribute/property values can include
an indication of the language of the literal;

- amend description of attribute Identifier (property dc:identifier) to
state that an identifier should be globally unique;

- amend description of attribute Title (property dc:title) to indicate
that repeatability applies only for multiple language representations of
a single main title;

- add description of attribute Alternative Title (property
dcterms:alternative), optional, repeatable;

- amend description of attribute Type (property dc:type) to remove
reference to RSLP Collection Type encoding scheme and recommend "DCMI
Collection Type Vocabulary" scheme (see below);

- amend description of attribute Language (property dc:language) to
indicate that values should conform to the specified encoding schemes,
and free text is not permitted;

- remove description of attribute Note;

- amend description of attribute Concept (property dc:subject) to alter
label to "Subject" and permit other subject schemes recommended by DCMI,
and also UNESCO Thesaurus (see below);

- amend description of attribute Place (property dcterms:spatial) to
alter label to "Spatial Coverage", and revise definition to specify that
it applies to the content of the items in the collection;

- amend description of attribute Time (property dcterms:temporal) to
alter label to "Temporal Coverage", and revise definition to specify
that it applies to the content of the items in the collection;

- add UNESCO Thesaurus as encoding scheme (for dc:subject);

- add "DCMI Collection Type Vocabulary" as encoding scheme (for
dc:type), where this scheme provides a set of collection types/classes
"corresponding to" the resource types/classes in the DCMI Type
Vocabulary (Collection of Texts, Collection of Images etc).


The following points have been mentioned/discussed to a greater or
lesser extent but I'm less sure we have reached any consensus:

- use of the hasLocation attribute/property to specify the identifier of
a Service that makes available a digital Collection. Or coin a distinct
hasService (or something like isMadeAvailableBy? - hasService doesn't
say much about the type of relation) property for this?

- use of the attribute Strength - is it useful as free text or only with
an encoding scheme?

- use of the attribute Accrual Status - free text? specify an encoding
scheme based on current guideline?

- addition of attribute Size of Collection (dcterms:extent) distinct
from Physical Characteristics (dc:format)? (Not sure whether
dcterms:medium would be useful - for physical collections only)

- addition of attribute Logo (identifier of image related to
Collection);

- addition of attributes to describe (a) copyright and (b) licensing
conditions, separately from Access Controls;

- the BioCase schema highlighted by Charles Copp

http://www.biocase.org/Doc/Results/results.shtml

does offer some additional attributes/properties - I think most of them
are applicable primarily to a specific subclass of Collections, but
please shout if there are attributes that look more generally useful
that we should consider including.

- the MPV spec highlighted by Vladimir Portnykh

http://www.osta.org/mpv

appears to be primarily concerned with describing the "packaging" of
items into "collections" (a bit like METS, maybe?). It supports the use
of metadata conforming to external schemas to describe resources - so
for example, I think metadata based on an AP developed here might be
used in an MPV instance to describe a collection. But I couldn't see
where it specified its own attributes for describing a collection in the
sense we are discussing here?

Cheers
Pete
-------
Pete Johnston
Interoperability Research Officer
UKOLN, University of Bath, Bath BA2 7AY, UK
tel: +44 (0)1225 383619    fax: +44 (0)1225 386838
mailto:[log in to unmask]
http://www.ukoln.ac.uk/ukoln/staff/p.johnston/