Title: DCMI property domains and ranges
Readings included in the meeting packet:
-- DC property domains and ranges
[This is a snapshot of dublincore.org/usageboardwiki/PropertyDomainsAndRanges]
-- 2006-06-28 proposal to assign ranges to /terms/ properties, but not /1.1/ properties
-- Digest of discussion on list
-- educationLevel (let's vote this time)
In Seattle, the Usage Board supported the idea of replicating
the fifteen DCMES elements in the DCTERMS namespace.
In addition, the following points were made:
-- Several other DCMI vocabularies might be defined and
identified with URIs [NEEDED-TERMS]:
-- DCMI Abstract Model entities
-- Terms for describing Application Profiles
-- Terms for describing DCMI terms (e.g., Status)
-- A controlled vocabulary of types of Status
-- The domains and ranges vocabulary
-- Many of the domain and range proposals are probably
uncontroversial. Some notable exceptions:
-- dcterms:educationalLevel [EDUCATIONLEVEL]
-- dc:creator and dc:creator [DC-RDF-NOTES]
A clarification of how to implement the agent elements
is on the critical path to assigning domains and ranges
to DCMI properties.
Given the 'stages' that we identified in Seattle, I think we need to
focus only on stage 1, i.e.
1. Approve the semantics of the classes [buy in,
public comment, f2f UB meeting, community consensus]
2. Approve the application of these classes as domains
and ranges for DCMI terms [buy in, public comment,
f2f UB meeting, community consensus]
1.1 is about agreeing that we have identified the correct
set of classes and that the semantics of those classes
1.2 is about agreeing to the principle that we should
assign domains and range to either 1) 'all DCMI properties'
or 2) 'all the properties in the DCTERMS namespace'.
(I prefer the latter approach).
In both cases, we should also agree a timeline of
actions to ensure buy in, public comment, f2f UB meeting,
I'd recommend that we deal with 1.2 before we deal with
1.1 and then agree the timeline/actions.