I have to agree with the concerns expressed by the various
objectors to the newly introduced terminology. Some details:
1. "Semantic refinement" as a qualifier class is pretty ugly - semantically
refine what?? (from the context, I think it is the element meaning).
The word "semantic" is pretty redundant in this position.
2. I hate the use of "Object" as one of the "Object types" - re-use
of the same word requires too subtle an understanding of context to
reliably disentangle the meaning of the tokens. I suggest that
"Instrument" serves well enough instead.
But in particular:
3. The ballot appears to be attempting a major clarification of the
data-model or reference-model, while simultaneously asking us to approve
a bunch of instances associated with it. I don't think that this is
achievable yet.
Just after Frankfurt I put together a little discussion piece "Inline
or Outlaw" http://www.agcrc.csiro.au/projects/3018CO/metadata/dc-id/
on aspects of the DC datamodel. I was interested in exploring the impact
of the DCT1 list of types, which I took to define the scope of resources
that can be described by DCMES.
In the table in this paper, in the column headed "Scope of Value", I
attempted to discover the "type" of the values of DC elements, where
possible as a value from DCT1. I suspect that this is approximately
the same as the Object Type introduced in the ballot.
People may like to look at this paper to see if it sheds any light ...
(but note the date on the bottom).
In effect, I laid out, briefly, the part of the data-model
concerning *values*. We need to agree that something along these
lines makes sense, and also conduct a similar exploration of the
part of the data-model concerning *elements*, in order to ensure
that we are on the same page (i.e. are working from the same
reference-model) in order to continue with the ballot. I also
strongly feel that we need to refer to a bunch of worked examples
as a reality check at each stage.
[ My other concern in the piece was that in many cases (perhaps all,
if Eric has his way! ;-)) the values of DC elements should typically
contain an identifier, such as a URL. The combination of the 1:1
rule and the DCT1 list of DC types seems to me to imply that we must
distinguish between cases where the value identifies a resource
in-scope for DCMES - in which case the identifier points to another
DC resource and thus should not be de-referenced inline - and those
cases where the identifier merely points to a convenient storage
location for a text string or other piece of information - in which
case the value can be de-referenced with impunity. ]
--
Best Simon
|