Again, IMHO a clean vote on *element-refiners* is
"do the values on list XXXX refine DCMES element YYYY?"
In other words we should consider complete, named, lists of refiners for each element.
Some of the "lists" may only have a single member, but that is OK.
So alongside MARC-Relators and AAT-roles for Contributor we have
DCMI-RelationTypes (IsBasedOn, HasPart, etc) for Relation,
DCMI-FormatTypes (Extent, Medium) for Format,
DCMI-TitleTypes (Alternative) for Title,
DCMI-CoverageTypes (Place, Time) for Coverage, etc, etc.
The vote should be two-part - for those lists that are proposed by DCMI
we can vote on the contents, and have a separate vote on whether
the list as a whole is useful for the particular element.
This modularises the element-refinement problem in the same way that
encoding-schemes modularises the structured-value problem.
This would solve the "role" problem and allow it to inhabit the same
framework as for all the other refiners for the other elements.
At least recommend this for *implementation*.
(We need to get the registry happening.)
--
Best Simon
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|