There have been a couple people that have responded to the pre-ballot
document indicating that DCPeriod was not officially endorsed by the
date/coverage group. While I was surprised at this position, a quick review
of the WG deliverables revealed this to be true. And, in a haste for
getting the ballot out the door for peer review, I temporarily removed this.
Part of the reason I was surprised at this was because I thought we had
general consensus on this point, unfortunately after checking, some of this
discussion did not occur on the dc-usage on the list. (Note: keep
discussions public so we can reference in the future!) The attached message
was a proposal that had consensus for addressing the range issues identified
by the date and coverage group. While the DCPeriod encoding scheme (per se)
was not approved by these working groups, the functional requirements for
satisfy date-ranges certainly were. In the lack of no other identified
encoding scheme for satisfying these ranges (no W3CDTF does not work for
ranges) and in the extensive discussions [1][2][3] and general support both
on and off the list, I'd strongly suggest re-introducing this in the ballot
for voting.
eric
[1] http://www.mailbase.ac.uk/lists/dc-usage/2000-02/0016.html
[2] http://www.mailbase.ac.uk/lists/dc-usage/2000-01/0141.html
[3] http://www.mailbase.ac.uk/lists/dc-usage/2000-02/0006.html
-----Original Message-----
From: Miller,Eric
Sent: Wednesday, February 02, 2000 11:04 AM
To: 'Andy Powell'; Simon Cox (E-mail); Renato Iannella (E-mail)
Subject: RE: DCMI Date Range
The recent discussion on date ranges, and the fact that there is no defined
(yet) specification for the encoding rules for the DCMI Date Range, leads me
to the following suggestion... Is the following an acceptable modification
to the current DCMI Date Range balloting item:
Label: DCMI Period
Defintion: A specification of the limits of a time interval, and methods for
encoding this in a text string.
See also: http://www.agcrc.csiro.au/projects/3018CO/metadata/dcperiod/
Qualifier Class: Encoding Scheme
I believe it basically is a clarifcation on what is suggested by the DC Date
Group, and would not alter the current votes, but I'm looking for
confirmation on this before I suggest this to the dc-usage group.
Simon... the machine www.agcrc.csior.au (which is an alias to
disco.den.dem.csiro.au) traceroutes fine, but seems that the web server is
down? Can we restrt this? and if not, can you suggest an alternate URL for
document? If these encoding schemes (period, box, etc.) are endorsed I'd
like to eventually move these to the DC (and consequently DC-mirror) sites
with appropriate authorships, etc. Would this be all right with you?
--
eric
> -----Original Message-----
> From: Simon Cox [mailto:[log in to unmask]]
> Sent: Tuesday, February 01, 2000 7:09 PM
> To: [log in to unmask]
> Subject: Re: DCMI Date Range
>
>
> Andy - there was no formal proposal when the ballot was assembled.
> I've attempted to fill the gap with my draft
>
> "DCPERIOD - specification of the limits of a time interval, and
> methods for encoding this in a text string"
>
> http://www.agcrc.csiro.au/projects/3018CO/metadata/dcperiod/
>
> which follows the dcbox, dcpoint style closely. DCPERIOD may need
> a little fine-tuning, but I believe that it is good enough to serve
> the purpose here. There is a big advantage in shifting the detail
> into a secondary spec like this, I think, while agreeing in-principle
> that a DCPERIOD scheme is what we need, as well as the
> obvious scalability
> and modularity wins.
>
>
> Andy Powell wrote:
> >
> > Can someone help me... I know I'm being stupid - what is
> the URL for the
> >
> > DCMI Date Range
> >
> > proposal on the Date voting form?
> >
> > Andy
> > --
> > Distributed Systems and Services
> > UK Office for Library and Information Networking
> > University of Bath, Bath, BA2 7AY, UK Voice: +44
> 1225 323933
> > www.ukoln.ac.uk/ukoln/staff/a.powell Fax: +44
> 1225 826838
> > Resource Discovery Network -
> www.rdn.ac.uk
>
> --
> Best Simon
>
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|