W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > July to September 2004

Proposed reply to: Bjoern Hoehrmann, Access to date and time information

From: Tom Adams <tom@tucanatech.com>
Date: Tue, 7 Sep 2004 09:55:38 -0400
Message-Id: <9968C582-00D5-11D9-ABF1-000A95C9112A@tucanatech.com>
To: DAWG <public-rdf-dawg@w3.org>

A proposed reply to Bjoern Hoehrmann's "Access to date and time 
information", full text below. See comments to the list in 
<list-comment/>.


---


Hi Bjoern,

Thanks for sending comments to the DAWG.

>   http://www.w3.org/TR/2004/WD-rdf-dawg-uc-20040602/#u2.4 seems to
> motivate a requirement that is not listed in the draft. At some point
> in the process, the software needs to know the current date and time
> for example to avoid to schedule the recording of outdated items, or
> it needs to know how to group dates to weeks in order to present the
> index page for each week's recorded items.

Some questions for you so we get a better idea of your thinking:

o Do you feel that this is something that should be part of a standard 
access protocol?

o How does it help you as a developer to have it as part of an RDF 
access protocol, rather than part of some other network protocol (e.g. 
NTP)?

o How would you see such a function being embedded in the protocol? For 
example, if a HTTP based protocol were to be adopted, would it be 
embedded in the headers?



<list-comment>
Does anyone else feel that this it beyond our scope? This is already 
address in some network protocols. Perhaps as part of any HTTP based 
protocol we could bundle it in the header??
</list-comment>



> Another use case here would be a software program to remind working
> groups of the "Heartbeat" Requirement using TR Automation [2]; a query
> language could enable a query for all the technical reports not in an
> end state that are older than 2 1/2 month, or all groups that published
> a technical report that is not in an end state, that have not published
> an update of one of those drafts for 2 1/2 months.
>
> Hmm, this also motivates Requirement 3.7, "Limited Datatype Support";
> since there is so far only one use case that motiviates datatype
> support, it might be good to add this motivation to the Monitoring News
> Events use case.

Good point, only UC 2.7 discussed this currently. I'll ask the DAWG for 
further comments on whether we need more use cases that address this 
requirement.


<list-comment>
Do we have a need to address more use cases to datatype support? Is it 
sufficient that we only have one use case that addresses this 
requirement?
</list-comment>


-- 
Tom Adams                  | Tucana Technologies, Inc.
Support Engineer           |   Office: +1 703 871 5312
tom@tucanatech.com         |     Cell: +1 571 594 0847
http://www.tucanatech.com  |      Fax: +1 877 290 6687
------------------------------------------------------
Received on Tuesday, 7 September 2004 13:55:41 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:20 GMT