On Mon, 23 Jul 2001, Thomas Krichel wrote:
> Andy Powell writes
>
> > I make 8 recommendations. It's not finished yet - I'd like to add
> > something about mixing DC metadata with other metadata schemas. And I
> > have references to add. Nevertheless, I'd welcome comments on these
> > guidelines, both on whether such guidelines are useful in principle and
> > on whether these particular guidelines are the right ones!
>
> I do not see the rationale for recommendation 6, which seems
> to be out of line with recommendation 7. I am not saying that
> this is wrong, but a few more words may be helpful there.
Yes agreed. The rationale is that all element refinements in DC are just
new properties that happen to refine existing DC elements. dct:extent is
an element refinement of dc:format - therefore dct:extent is a new
property that has narrower semantics than dc:format.
The important point to remember is that dct:extent may have refinements of
its own. For example, in the future we may define dct:duration to be an
element refinement of dct:extent. If people have chosen to implement
element refinements differently from other properties they may find that
they can't implement hierarchical refinements very well. For example, if
dct:extent is implemented as
<dc:format refinement="extent">...</dc:format>
how would dct:duration be encoded? If instead, you simply treat all
elements and element refinements consistently in the encoding, i.e. treat
them all as properties, then anthing you can do with one, you can also do
with the other.
There are some advantages with a nested approach, e.g.
<dc:date>
<dct:available>
2002-06
</dct:available>
</dc:date>
or
<dc:format>
<dct:extent>
<dct:duration>
25 minutes
</dct:duration>
</dct:extent>
<dc:format>
most obviously because dumbing-down is possible based solely on the
instance metadata.
However, my gut feeling is towards having the simplest instance metadata
<dct:extent>
25 minutes
</dct:extent>
leaving dumb-down problems for future registry-based solutions. This
approach is broadly consistent with the proposed treatment of element
refinements in the RDF/XML draft recommendation.
Encoding schemes are different because they are telling you something
about the value (much as xml:lang does). Therefore, encoding the scheme
as an attribute of the XML element seems sensible. I note however, that I
haven't specified a separate namespace for 'scheme' and therefore each
implementation will have its own attribute called 'scheme' :-(.
Andy
--
Distributed Systems and Services
UKOLN, University of Bath, Bath, BA2 7AY, UK [log in to unmask]
http://www.ukoln.ac.uk/ukoln/staff/a.powell Voice: +44 1225 323933
Resource Discovery Network http://www.rdn.ac.uk/ Fax: +44 1225 826838
|