> From [log in to unmask] Fri Sep 27 09:26 MET 2002
> MIME-Version: 1.0
> Date: Fri, 27 Sep 2002 08:26:40 +0100
> From: Rachel Heery <[log in to unmask]>
> Subject: Re: multiply affiliated refinements
> To: [log in to unmask]
>
> On Fri, 27 Sep 2002, Andy Powell wrote:
>
> >
> > 3) Carefully fit any newly proposed refinements for dc:creator and
> > dc:contributor directly under one or other (but not both) of those
> > elements. E.g. I would consider dcterms:editor as an element refinement
> > of dc:contributor, not dc:creator.
>
> I think this would be rather too restrictive.... some implementations may
> just want to use dc:creator and not bother with dc:contributor. In which
> case this solution denies them the opportunity to use DCMI approved
> qualifiers. I would hope that the syntax constraints would allow for the
> flexibility to use the various 'agent' qualifiers with each of the 'agent'
> elements.
The core point is, that
dc:contributor
dc:creator
dc:publisher
are agentRoles as xy:illustrator xy:editor xy:censor and whatever.
Typically these semantics are not subOrdinated to dc:CCP as
CCP is based on responsibility.
Such elements can be used in parallel with DC and i don't see
any reason, why DCMI should re-do the work others have done.
If one starts to force subProperty relations DCMI would have to
create gadgets like creatorEditor contributorEditor publisherEditor .....
...and sooner or later we will have creatorEditorManaging
and will discuss about the deputy mananging editor on whether she/he
can happen to act as a creator (the first executive managing editor
might just have been out for a DC Meeting)
So: This approach doesn't scale.
Take things in parallel - saves lots of namespace engineering issues
and other unnecessary discussions and hasty conclusions.
rs
>
> Rachel
>
>
> ---------------------------------------------------------------------------
> Rachel Heery
> UKOLN
> University of Bath tel: +44 (0)1225 826724
> Bath, BA2 7AY, UK fax: +44 (0)1225 826838
> http://www.ukoln.ac.uk/
>
>
|