Rule latest timestamp

Support
1

Hi,

I have following rule:

prefix resources: http://www.mycompany.com/resources#
prefix sosa: http://www.w3.org/ns/sosa/
prefix qudt: http://qudt.org/schema/qudt#
IF {
?o a sosa:Observation .
?o sosa:observedProperty http://www.mycompany.com/resources#Humidity .
?o sosa:hasFeatureOfInterest ?foi .
?o sosa:phenomenonTime ?t .
?o sosa:hasResult ?r .
?r qudt:numericValue ?v .
FILTER (?v > 40) .
}
THEN {
?foi resources:hasHumidity http://www.mycompany.com/samples/weather#MoistHumidity
}

How can I make sure that I grap the latest observation in the IF clause (?t is holding the timestamp). In queries I order the selection combined with LIMIT 1.

Kind regards,
Johan

2

I’m sorry but I don’t think I quite understand your question. Can you elaborate on what exactly you’d like to do in the rule and what exactly you’d like to do in the query.

If you’re trying to apply the rule to the latest observation ?t, I don’t think you can do that unless maybe you had a predicate pointing to the previous observation like ?o soa:previousObservation ?prev although someone may come up with something clever I haven’t thought of.

3

My rule should only take the latest observation ?o into account when making its decision in the then clause.

Now the rule takes into account all ?o in the database.

When i query for data i can use order on ?t descending and limit the nummer of results to one.

What i need is the same functionality in my rule.

Thanks for helping me!

Johan,

4

That was my previous understanding. I can’t say definitively that you can’t do it but my intuition tells me that you can’t. If you can remodel your data to include a ?prev you might be able to use a property path.

5

I found a workaround by tagging my observations with a latest predicate. Each time before I insert an observation I fetch the latest and update the tag. This way I always know which observation individual is the latest.

I wonder whether there is another less intrusive solution…

Kind regards,

6

You might be able to write a custom transaction listener. There is an example in the stardog-examples repo stardog-examples/examples/connectable at develop · stardog-union/stardog-examples · GitHub

I'm not an expert on description logic but I think there are some fundamental problems that aren't going to allow you to use the reasoner. Hopefully I get this right and don't make a mistake but hopefully if I say something too boneheaded it will compel someone like @pavel to correct me :slight_smile:

I don't think what you're looking to do is monotonic. Being monotonic would mean that adding data would never result in fewer valid inferences. Although the total number of inferences would remain the same, only one can be the latest, I think they also need to be stable. I don't think you can have a single inference that bounces around.

You might also be able to get what you're looking for by storing that particular bit of information in a relational database and mapping it in using virtual graphs but now managing your data gets much harder. I think the transaction listener route would be the best way to go.

7

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.