Materialized inferred values in GraphQL queries

[Michael Panzer]

Hi,

does anybody know if, given a sh:values rule that is materialized, the GraphQL engine still does on-the-fly inferencing of values (even though the triples are in the graph)?

My hunch is that it does. We are seeing very slow performance from GraphQL queries and trying to narrow down if this is related to inferred values.

Cheers

Michael

[Holger Knublauch]

Quite possibly yes. For these properties, the engine will look both for asserted and inferred values.

Have you tried removing the sh:values rules (temporarily) and run the same queries, comparing the execution time?

If you assert them anyway, would it make sense for you to have these sh:values rules disabled for the runtime system?

Holger

--
The topics of this mailing list include TopBraid EDG and related technologies such as SHACL.
To post to this group, send email to topbrai...@googlegroups.com
---
You received this message because you are subscribed to the Google Groups "TopBraid Suite Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to topbraid-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/bf448cae-0bfa-4837-ae62-6b949e1b7c1an%40googlegroups.com.

[Michael Panzer]

We have not already done this, but will give it a try.

Michael

[Davide Sottara]

Hi Holger, Michael,

I have a related question. In the following query:

query myQuery($id : ID, $value: String) {

   myClass(
      uri: $id
      inferred: $value
   ) {
     label
   }
}

if "inferred" is a property with an inference rule, is it possible that the inference 
is executed for all instances of myClass, before the filtering by $id (and $value)?
More generally, is there any kind of query planning in the GraphQL engine, 

and/or how does it integrate with the inference rules?

We can always refactor our queries and/or materialize the triples, but any insight 

on the engine inner workings would surely help.

Thank you!!

[Holger Knublauch]

Correct, filtering on inferred values is very inefficient, because there is no general "inverse" of sh:values rules.

Best to be avoided by asserting the inferences or querying the asserted triples that are the base of the rules.

What sort of inferences do you need to query? Maybe there is a way to optimize those...

Holger

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/869a599d-37ab-418f-96bb-e859f8d45913n%40googlegroups.com.

[Davide Sottara]

Hi Holger

Thank you for confirming our hypothesis

Yes, in general we can materialize the triples, or rewrite the queries.

One use case stands: sometimes we work with structured, encoded data.

This is not the real use case, but along the lines:

subj

  myCodedAttribute: "AA-xyz-1234" 

which can be deconstructed:

subj

  myCategory: "urn:AA"

  mySource: "urn:xyz"

  myIdentifier: "1234"

Keeping these triples inferred allows to save space for large datasets,

especially if we query by one "subj" URI at a time, but then we hit the
performance penalty if we query the entire dataset by, say, "myCategory".

Other than rewriting the query or the dataset, we can also query by subj,

and then filter by category client-side.

We'd rather not use ad-hoc javascript code except in extreme cases

Davide