AW: Action 695 argument

> No because each time you run the rule set you potentially get a 
>different result. The model and entailments for a rule set are no longer 
>defined by the rule set but are context dependent and the model theory 
>does not have a notion of an external context through which to inject 
>this extra constant.


Right, we would need to extend RIF with a temporal logic and the notion of
state. For instance, in terms of variant of the event calculus where the
function "fn:current-dateTime" is modeled as a fluent, i.e. a mapping into a
changeable state in the context of a time point or time interval.

However, this is out of the scope of BLD and Core but could be addressed by
PRD which already has a notion of state (snapshot of a Herbrand
interpretation). Nevertheless, for many real word scenarios, as e.g. for
several use cases in UCR, we need such expressiveness.

-Adrian


-----Ursprüngliche Nachricht-----
Von: public-rif-wg-request@w3.org [mailto:public-rif-wg-request@w3.org] Im
Auftrag von Dave Reynolds
Gesendet: Donnerstag, 12. Februar 2009 10:09
An: Gary Hallmark
Cc: Changhai Ke; RIF WG
Betreff: Re: Action 695 argument


Gary Hallmark wrote:
> 
> 
> On Wed, Feb 11, 2009 at 3:59 AM, Dave Reynolds <der@hplb.hpl.hp.com 
> <mailto:der@hplb.hpl.hp.com>> wrote:
> 
>     Gary Hallmark wrote:
> 
>           * How do I reference the current datetime (e.g.
>         fn:current-dateTime
>             <#func-current-dateTime>)
> 
> 
>     Separate from the semantic problems for BLD that Jos correctly
>     points out, 
> 
> I still don't see any semantic problems.  Isn't a current-date builtin 
> equivalent to a current-date constant and an equality formula like 
> rif:current-date = "2009-02-11T12:30+02:00"

No because each time you run the rule set you potentially get a 
different result. The model and entailments for a rule set are no longer 
defined by the rule set but are context dependent and the model theory 
does not have a notion of an external context through which to inject 
this extra constant.

>     would fn:current-dateTime return an xsd:dateTime with or without a
>     timestamp?
> 
> 
> from the xpath spec:
> |fn:current-dateTime|()| as ||xs:dateTime|
> Summary: Returns the current dateTime (with timezone) from the dynamic 
> context.  

Sure, I meant to put a :-) after that to indicate slightly 
tongue-in-cheek rhetoric. Clearly that is the normal and obvious 
definition, hence my problems with Changhai's examples.

>     To meet Changhai's use cases it would have to be without a timestamp
>     while for many reasonable usecases it would have to be with one.
> 
> Not if we include the adjust timezone builtins.  These let you convert 
> timezones, including to/from no timezone.

If you are prepared to do such conversions in your rules then can't you 
take a with-timezone constant and convert it to the timezone of the 
current-dateTime anyway? I thought the argument for having 
without-timezone dateTimes was to avoid such explicit timezone hacking.

Dave
-- 
Hewlett-Packard Limited
Registered Office: Cain Road, Bracknell, Berks RG12 1HN
Registered No: 690597 England