W3C home > Mailing lists > Public > public-wai-ert@w3.org > June 2007

Antw: RE: [HTTP-in-RDF] date properties for timestamping

From: Reinhard Ruemer <Reinhard.Ruemer@jku.at>
Date: Tue, 12 Jun 2007 14:48:04 +0200
Message-Id: <466EB212.B98F.00B0.0@jku.at>
To: <public-wai-ert@w3.org>

Hi all,

Mag. Reinhard Ruemer
Universitaet Linz
Institut Integriert Studieren
Altenbergerstrasse 69, A-4040 Linz
Tel.: +43 (0)732 2468 1273
E-Mail: reinhard.ruemer@jku.at
WWW: http://www.integriert-studieren.jku.at

>>> "Carlos Iglesias" <carlos.iglesias@fundacionctic.org> schrieb am
Sa, Jun 9,
2007 um  2:21 am in Nachricht

> Hi Shaid,
>> >> possible candidates for timetamping properties are:
>> >>
>> >> * dc:date (for both http:Request and http:Response); here we
>> >> have to clarify that the times are to be measured at the
>> >> client and not to be confused with the Date HTTP header.
>> >> * dc:dateSubmitted (for http:Request) and dc:dateAccepted (for
>> >> http:Response)
>> >
>> > I more in favour of dc:date because I think it's definition, "A
point or
>> period of time associated with an event in the lifecycle of the
>> resource.", covers perfectly our use cases.
>> >
>> > Don't like dc:dateSubmitted and dc:dateAccepted too much because I
>> their current definitions "Date of submission of the resource (e.g.
>> thesis, articles, etc.)" and "Date of acceptance of the resource
(e.g. of
>> thesis by university department, of article by journal, etc.)"
>> respectively, manage slightly different concepts:
>> >
>> >  -  Request sth vs. submit sth, which are more or less the
>> >  -  Respond to sth vs. acceptance of sth, a kind of respond.
>> I agree that the current descriptions of dateSubmitted and
>> focuses more on printed materials but I think it makes sense to
>> this to electronic resources too. After all, you *submit a request*
>> *accept a response*. Maybe we should ask for clarification on a DC
>> or forum?
> Maybe, but I'm not sure.
> Submit a request sounds OK, but accept a response sounds strange for
me as 
> it could cause confusion with accepted response codes (202).

since the two elements are different (dc:dateAccepted and
http:responseCode) I don't think that it would cause theat much of a
> Anyway, what's the problem with dc:date? For me its definition "A
point or 
> period of time associated with an event in the lifecycle of the
resource." is 
> just perfect, as it adapts to the context in any use case.

...nevertheless I also agree with earlier posts to use dc:date for both
(request and response)

Received on Tuesday, 12 June 2007 12:48:25 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:55:55 UTC