> 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 EnglandReceived on Thursday, 12 February 2009 09:31:38 UTC
This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:07:53 UTC