Summing in rules

[Mads Holten Rasmussen]

This is actually a two in one question as I have tried two approaches to solving my problem.

Problem

For each pipe (:P) and hub (:H) in the tree I need to sum up the flow. The consumers(:C) each have a flow which is fed by the source (:S) - the root of the tree.

Approach 1 - Stardog rule

On the attached graph the following query gives me the total flow in hub H1:

SELECT (SUM(?fl) AS ?totFlow) 

WHERE {:H1 ^ont:fedBy+/ont:flowConsumption ?fl}

Returns totFlow = 8.

When I try modelling the query as a rule I get no results. Can it be that inverse property paths and arbitrary length matches are not supported when writing rules?

        IF {

            ?p ^ont:fedBy+/ont:flowConsumption ?fc .

        }

        THEN {

            ?p ont:indirectConsumption ?fc .

        }

Approach 2 - OWL transitive property + property chain axiom

The following infers the indirect consumptions to each pipe or hub (see flow_simple2.pdf):

ont:feeds a owl:ObjectProperty ,
                        owl:TransitiveProperty ; 
                 owl:inverseOf ont:fedBy . 

ont:indirectConsumption a owl:DataTypeProperty ;
        owl:propertyChainAxiom ( ont:feeds ont:flowConsumption ) .

This means that each node will have several indirect consumptions attached to it. How do I sum them up? The following doesn't return any results:

        IF {

            ?p ont:indirectConsumption ?fc .

            BIND(SUM(?fc) AS ?tot)

        }

        THEN {

            ?p ont:flow ?tot .

        }

[Zachary Whitley]

Looking at the SPARQL property paths spec I believe that both are supported. I seem to remember some discussion a little while ago of a feature that was left out at the last minute...exact length perhaps. Try looking in the logs and see if there is anything in there after firing the rule. I think this might be a case of a cycle in the rule. I'm still a little fuzzy on identifying these cases. See [1] for an explanation.

[1] http://docs.stardog.com/#_rule_limitations_gotchas

On Thu, Jan 26, 2017 at 6:16 AM, Mads Holten Rasmussen <mads.h.r...@gmail.com> wrote:

Is it true that inverse property paths and arbitrary length matches are not supported when writing rules?

On the attached graph the following query gives me the total flow in hub H1:

SELECT (SUM(?fl) AS ?totFlow) 

WHERE {:H1 ^ont:fedBy+/ont:flowConsumption ?fl}

Returns totFlow = 8.

For now I just wanted to infer the indirect consumptions by the following rule:

        IF {

            ?p ^ont:fedBy+/ont:flowConsumption ?fc .

        }

        THEN {

            ?p ont:indirectConsumption ?fc .

        }

which doesn't return any results.

I know I can do this by adding the following to my ontology (see flow_simple2.pdf), but I wanted to do it with a rule:

ont:feeds a owl:ObjectProperty ,
                        owl:TransitiveProperty ; 
                 owl:inverseOf ont:fedBy . 

ont:indirectConsumption a owl:DataTypeProperty ;
        owl:propertyChainAxiom ( ont:feeds ont:flowConsumption ) .

For the summation, I am kind of lost no matter if I have the indirect flow consumptions added to the node or not.

--
-- --
You received this message because you are subscribed to the C&P "Stardog" group.
To post to this group, send email to sta...@clarkparsia.com
To unsubscribe from this group, send email to
stardog+unsubscribe@clarkparsia.com
For more options, visit this group at
http://groups.google.com/a/clarkparsia.com/group/stardog?hl=en
---
You received this message because you are subscribed to the Google Groups "Stardog" group.
To unsubscribe from this group and stop receiving emails from it, send an email to stardog+unsubscribe@clarkparsia.com.

[Evren Sirin]

Neither aggregation nor recursive property paths are allowed in rules. I just committed changes to the section Zachary referenced to include more detailed information about valid rules. Once the website is updated item 3 will look like this:

Stardog Rule Syntax has the same expressivity of SWRL which means the SPARQL features allowed in rules are limited. Specifically, a triple pattern in a rule should be in one of the following forms:

a) term1 rdf:type class-uri

b) term1 prop-uri term2

where class-uri is a URI referring to a user-defined class and prop-uri is a URI referring to a user-defined property.[30]

Only type of property paths allowed in rules are inverse paths (^p), sequence paths (p1 / p2) and alternative paths (p1 | p2) but these paths should not violate the above conditions. For example, the property path rdf:type/rdfs:label is not valid because according to the SPARQL spec this would mean the object of a rdf:type triple pattern is a variable and not a user-defined class.

Rule body (IF) and only rule body may optionally contain UNION, BIND or FILTER clauses. However, functions EXISTS, NOT EXISTS, or NOW() cannot be used in rules. User-defined functions (UDF) may be used in rules but if the UDF is not a pure function then the results are undefined.

Other SPARQL features are not allowed in rules.

[Mads Holten Rasmussen]

In accordance with Evren's reply I can confirm that inverse path works, but this is quite useless as I could just have switched the variables. I also need the sequence path to be of arbitrary length in order to do something useful with it. Since I can not do a summation it will not help me anyway.

I can see that SPIN supports aggregations. Will this feature be supported by Stardog in the future?

[Mads Holten Rasmussen]

Let me try a different approach then. Is there a way to perform a query that first infers the missing triples and then inserts them in the database with an INSERT?

SELECT ?p (SUM(?fl) AS ?totFlow)
WHERE {
  ?p ^ont:fedBy+/ont:flowConsumption ?fl 

}
GROUP BY (?p)

INSERT { ?p ont:flow ?totFlow } 

On Thursday, 26 January 2017 12:16:51 UTC+1, Mads Holten Rasmussen wrote:

[Stephen Nowell]

Hi Mads,

You can accomplish this with an INSERT query that contains your SELECT as a subquery:

INSERT { ?p ont:flow ?totFlow }

WHERE {
    SELECT ?p (SUM(?fl) as ?totFlow) WHERE {

        ?p ^ont:fedBy+/ont:flowConsumption ?fl
    }

    group by (?p)
}

Cheers,
Stephen

--

-- --
You received this message because you are subscribed to the C&P "Stardog" group.
To post to this group, send email to sta...@clarkparsia.com
To unsubscribe from this group, send email to

stardog+u...@clarkparsia.com

[Evren Sirin]

You can use a subquery inside an insert where clause:

INSERT { ?p ont:flow ?totFlow }

WHERE {

  { 

    SELECT ?p (SUM(?fl) AS ?totFlow)

    WHERE {

      ?p ^ont:fedBy+/ont:flowConsumption ?fl 

    }

    GROUP BY (?p)

  } 

}

Aggregation just like negation breaks monotonic reasoning which means adding a new triple changes previous inferred results. Then the inferences you get change based on the order of rule evaluation. Using explicit INSERT queries you can manage those issues in your application. In the future we plan to support both aggregation and negation in some way, e.g. when they occur outside cyclic rules, but probably not before the end of this year.

Best,

Evren

--

-- --
You received this message because you are subscribed to the C&P "Stardog" group.
To post to this group, send email to sta...@clarkparsia.com
To unsubscribe from this group, send email to

stardog+unsubscribe@clarkparsia.com

[Mads Holten Rasmussen]

@Stephen & Evren

Thank you. I will see if I can come op with some way of handling it this way.

I am looking forward to the support of aggregation and summation outside cyclic rules!

On Thursday, 26 January 2017 12:16:51 UTC+1, Mads Holten Rasmussen wrote: