In official documentation I can't find any information how to write conditional statements for java.util.Date type fact fields in guided rules. For example how to compare such field to current date, check if it is equal omitting time, or check if it is date before some time from now?
Drools isn't a real-time program and it doesn't have an innate idea of Time or Now. If you need to investigate relations of some fact property w.r.t. some point of time X, you'll have to establish a fact carrying X as its data, and write your rules based on that.
A more or less coarse approximation of a fact representing Now can be made using timers. You can implement a rule that modifies a fact containing a value representing Time (e.g. java.util.Date) every second, or less frequently.
Blending out the time of the day is something you'll have to do using Java or DRL functions. Alternatively, if it is days you are interested in, use some custom class representing days, with some suitable day 1 defined by you.
you can give like
inputDate>=11-Nov-2014
provide your current date to inputDate rule input Fact variable.
Related
I am facing a problem regarding the ability to enforce different resolutions of expressing time for different rdfs:Classes. I have a graph where:
:event a rdfs:Class.
:subevent rdfs:subClassOf :event.
and also related SHACL-rules where the event class requires its temporal existence reported only at the resolution of date, whereas the subevent is a more precisely defined point in time:
:eventSH a sh:NodeShape;
sh:targetClass :event;
sh:property [
sh:path :happeningOn;
sh:datatype xsd:date;
sh:minCount 1;
sh:maxCount 1;
].
:subeventSH a sh:NodeShape;
sh:targetClass :subevent;
sh:property [
sh:path :happeningOn;
sh:datatype xsd:dateTime;
sh:minCount 1;
sh:maxCount 1;
].
So, in an ontological sense, I have the need to express events at a varying resolution (some events are only known to occur on a certain year, some e.g. on a certain date, and some events are known to happen on a precise point in time).
In essence, the question is: is SHACL capable of expressing a constraint where the subevent timepoint must fall inside the superclass date? Is the only possibility to use SHACL-SPARQL for this? I understand that by nature year, month, day, date are different beasts compared to dateTime, as they are not points but rather ranges between two points in time.
I can't seem to find a function to convert dateTime to date, perhaps just casting into xsd:date would do it but not sure whether this is something most engines support in an unified way. So my primary question is - is this requirement of different resolutions for the same inherited predicate achievable in pure SHACL itself? Or should I resort to using different predicates with the help of e.g. OWL Time ontology? This would seem like an unnecessary complication compared to just using pure SHACL.
edit: As a clarification, I do recognize that in its current shape there is no possibility to define a subevent, as the shapes that restrict it are contradictory.
For this scenario you cannot use sh:datatype. Subclasses can only narrow down the constraints from superclasses. So if the superclass allows xsd:date then the subclass cannot constraint it further to xsd:dateTime. While it may sound intuitive to expect dateTimes to be a "subset" of dates, this is not how SHACL works, because it will compare the exact datatypes only, i.e. the URI of the datatype must match.
I also believe it would be very unusual to have a property that is either xsd:date or xsd:dateTime, depending on context. This makes it harder for applications to process. For example imagine an algorithm that is working against event and doesn't know about sub-event. Such an algorithm would be best if it could always assume xsd:date literals. One design alternative would be to define two properties, where the xsd:date property is always present (even for instances of the subclass), while the subclass may have another property to represent more details.
BTW to convert from xsd:dateTime to xsd:date, you can use xsd:date as a SPARQL function: BIND (xsd:date(NOW()) AS ?date)
I want to renew a variable if it is outdated - obviously this could be done with storing its creation time.
However - is there a (possilby undocumented) way of figuring out WHEN a variable in workspace was declared?
No, there is no way to know when a variable was created. People have explored the array metadata in detail, and nobody has found any indication of creation time stamps.
Furthermore, such a data field has no uses in general, and therefore are unlikely to be implemented, as a time stamp would just take up memory without providing a benefit.
For the very few cases where such a time stamp would be useful, I’d recommend creating a class that behaves like a normal numeric array, but additionally carries a time stamp.
I have a model in my Modelica and I use Dymola to compile this model. In my model I need the simulation information "Output Interval length". I have searched for it but I could not get the useful information. Is there any other possible way we could access simulation information.
If you are simply trying to get the results reported at specific intervals, you can use a sample operator to achieve that. That would force the solution to be computed at specific times without directly specifying something like the time step.
The important point to understand here is that a model where the behavior of the model depends on the numerical integration is highly suspect and I've never seen a case where the behavior couldn't be described without knowledge of the solution method. Said another way, "mother nature" doesn't know anything about "time steps". :-)
You could use a clocked system with an integrator.
For an Example, see File -->Libraries-->Modelica_Synchronous --> Examples --> Systems --> Controlled_mixing_unit in Dymola
There the period (i.e. in this case the timestep of the explicit Euler method) is a parameter of the periodic clock)
Modelica by design prohibits accessing any numerical solver internals, so you cannot access it. The output interval length also cannot be determined by the model in any reliable way since the solver will take internal steps longer than the output interval and then interpolate values for the result file.
You could create a function that reads the dsin.txt file and extracts that information.
I have started using drools a week ago.
I need to calculate average of a metric over a window-duration, say 4s. Below code-snippet of Drools will do this job.
... over window:time(4s) ...
However, I want to take this value as input to a rule with the value taken from control-panel UI where someone, say the customer, can specify the window duration.
I tried many options, including the one below, but that doesn't compile.
... over window:time($SlidingWindowDuration)
Googled for hours, but there is little documentation available on this subject.
Any clues in this regard would be of great help to me.
The length of a sliding window:time cannot be set dynamically. (I think this is so because dynamic lengths would make it impossible to infer an expiration offset for the automatic removal of obsolete events.)
Note that if this length can be set by the user before the engine is started and remains constant afterwards, you can insert the duration into the rule text, compile on the fly (only the rules that need last-minute editing) and execute.
To be absolutely dynamic, you'll have to implement the "window" mechanism explicitly. Make the timestamp an attribute of the event and set it explicitly: then you can base reasoning on timestamp differences, retract old events explicitly and compute the average over all that's left using a simple accumulate CE.
Should I store it in a single timestamp/datetime field or separate date and time fields? I prefer to store it as a single timestamp field but I need to know when a user didn't enter a time portion.
How to best store this in the database? I'm using postgresql.
There are definitely reasons why this is a bad idea. There are also reasons why your choices are limited. It's a bad idea because it's a single data item and for the more practical reason that you can't store a timezone if you have two fields.
As mentioned above, nulls are the obvious benefit of using two fields.
You might also want to consider using a single datetime field and storing a flag to indicate whether or not the user entered a time. This could be a boolean flag. However, you will still need to think about how you are going to use this data - entering only a date into a datetime field will lead to a time component being set to midnight. This will have implications in sorting and selection. Additionally, if you are storing timezones, you will have to be very careful when you use the data.
In order to fulfill your requirement of knowing whether or not a time was entered you will need to have two fields. You do not need the second field to be a time though.
The obvious answer is to use two separate fields; then you can use NULL values.
If you choose to use one field you will need to choose a magic time part that signifies "didn't enter a real time", which has the danger of coinciding with a real time (however unlikely).
Also, if you intend to use the date and time part separately often, then it might also be convenient to use separate fields; otherwise you will often need to use selection functions for extracting the relevant part of a field.