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

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
<09700B613C4DD84FA9F2FEA521882819020C6A1E@ayalga.fundacionctic.org>:

> 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
think
>> 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
opposite.
>> >  -  Respond to sth vs. acceptance of sth, a kind of respond.
>> 
>> I agree that the current descriptions of dateSubmitted and
dateAccepted
>> focuses more on printed materials but I think it makes sense to
extend
>> this to electronic resources too. After all, you *submit a request*
and
>> *accept a response*. Maybe we should ask for clarification on a DC
list
>> 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
confusion...
 
> 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)

Best
Reinhard

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