Thanks for identifying this. As in Erik's request for relation qualifiers,
the order of qualifiers will be preserved in the actual ballot.
eric
> -----Original Message-----
> From: Rebecca S. Guenther [mailto:[log in to unmask]]
> Sent: Thursday, March 02, 2000 9:17 AM
> To: [log in to unmask]
> Subject: Re: Preballot document for review
>
>
> Eric:
>
> I really don't understand why you ordered the elements as you
> did on the
> ballot (is there a meaning to this?). But I am particularly concerned
> about the order of the Resource type values. The working group made a
> point of putting the list in alphabetical order so as not to
> appear like
> some values are more important than others. I guess it's
> because you put
> "event" first, which may be the least likely of the values to be used,
> that it really bothers me. So, please reorder them into alphabetical
> order, as the working group presented it.
>
> Rebecca
>
> On Wed, 1 Mar 2000, Miller,Eric wrote:
>
> > Appended to this message is a link to the pre-ballot
> document that will be
> > used as the basis for the balloting system. Please review
> this document and
> > comment on this ASAP. I apologize in advance (again) if I
> have interpreted
> > any of the previous comments incorrectly. It was not my
> intention. There
> > have been several issues that have been identified in the
> recent months.
> > Some with clear solutions some without. Where the
> necessary 'fill in these
> > blanks' has occurred, I've tried to document these.
> >
> > A few points however should be mentioned:
> >
> > - Comments have been included where appropriate. it's still
> not clear which
> > kind of comment (general description or context for
> dc-usage) should be
> > included.
> >
> > - Tokens have been included for each of the items
> >
> > - Erik Jul raised the issue of grouping together
> like-qualifiers for the
> > relation
> > element. This is not done in this version of the document,
> but will be done
> > when the official ballot is introduced.
> >
> > - The DCMI Point, Box and Agent encoding schemes have been
> removed... they
> > have been identified by several people as not being
> endorsed by the various
> > working groups (date and coverage). Further investigation
> (via the WG
> > documents) confirmed this. We're there other deliverables
> from these groups
> > that the editors missed that support these encoding schemes?
> >
> > - And now for the big one... :)
> >
> > How exactly to compartmentalize the "agent core" vocabulary
> from the DCES
> > qualifier vocabulary was not initially clear. The concepts
> of 'agentType'
> > and the identification of two sets of these 'types' (AAT
> and MARC Relators)
> > I believe are intended to be used as means for refining the
> CCP elements.
> > No other working group focused on the mechanisms for
> refinement but rather
> > focused on the actual refining semantics. As such, it was
> not clear either
> > (a) how to incorporate this, or (b) where it belonged.
> >
> > Andy Powell identified this and proposed a way forward. His set of
> > refinements are aligned with the set identified by Rebecca
> and a set of
> > members on the MARC Relator Code working groups. These
> refinements I
> > believe satisfy the function requirements identified by the
> Agent working
> > groups through the notion of 'agentType' and are inline
> with the rest of the
> > elements notion of refinement.
> >
> > As such, the refinements identified by the LOC group for
> the CCP elements
> > are listed in the ballot and all have the value of an 'DCMI
> Agent'. The
> > vocabularies for defining tha describing DCMI Agent is in a
> separate set.
> >
> > Partitioning this as such seems to make a tremendous amount
> of sense...
> >
> >
> > I'll send the rest of the modification notes out tomorrow,
> but I wanted to
> > make sure people had a chance to see this...
> > http://rdf.dev.oclc.org/dc/dcqballot/DCQBallot-20000301.v2.html
> >
> > eric
> >
> >
>
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
