innovation in metadata design, implementation & best practices

Title: DCMI property domains and ranges
Created: 2006-09-03

Shepherd: Andy

Readings included in the meeting packet:

-- DC property domains and ranges
   [This is a snapshot of]

-- 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.

Andy writes:

Given the 'stages' that we identified in Seattle, I think we need to
focus only on stage 1, i.e.

    Stage 1
        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
    is clear.

    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,
    community consensus.

    I'd recommend that we deal with 1.2 before we deal with
    1.1 and then agree the timeline/actions.