feat(api-v2): Make inference optional in Gravsearch #1696
Conversation
- Clean up code a bit.
- Add docs.
- Add docs.
| val iriStr = iri.toString | ||
| iriStr == OntologyConstants.KnoraApiV2Simple.Resource || iriStr == OntologyConstants.KnoraApiV2Complex.Resource | ||
| } | ||
| lazy val KnoraApiV2ResourceIris: Set[IRI] = Set( |
There was a problem hiding this comment.
@benjamingeer question: why are using lazy val here in the following three cases? The initialization does not need any evaluation of an expression, it is just a set. In this case, it would not make any difference if the initialization happens immediately or is postponed to the first time the value is accessed.
There was a problem hiding this comment.
Great question! The problem is that KnoraApiV2ResourceIris is a static value (it's defined in an object rather than in a class), which refers to static values in another object. The order of initialisation of static values in the JVM depends on which object is loaded first by the JVM's class loader at run time. Without the lazy, if object KnoraApi is initialised before object KnoraApiV2Simple and object KnoraApiV2Complex, KnoraApiV2ResourceIris will just contain null values. It took me a little while to figure this out yesterday. A test was failing, and it turned out that it was because KnoraApiV2ResourceIris did not contain OntologyConstants.KnoraApiV2Complex.Resource, because it hadn't been initialised properly.
In the earlier code, there was a method, which didn't access those constants until it was called, so it was fine.
| triplestoreSpecificPrequery = QueryTraverser.transformSelectToSelect( | ||
| inputQuery = nonTriplestoreSpecificPrequery, | ||
| transformer = triplestoreSpecificQueryPatternTransformerSelect | ||
| ) | ||
|
|
||
| // _ = println(triplestoreSpecificPrequery.toSparql) | ||
| triplestoreSpecificPrequerySparql = triplestoreSpecificPrequery.toSparql | ||
| _ = log.debug(triplestoreSpecificPrequerySparql) |
There was a problem hiding this comment.
please remove this log
There was a problem hiding this comment.
Why? It should have no effect unless debug logging is enabled. Using log seems better than using println, because with println, you have to uncomment it and recompile if you want to use it. With log, you just have to change the logging config file.
| // println("++++++++") | ||
| // println(triplestoreSpecificSparql) | ||
| val triplestoreSpecificMainQuerySparql: String = triplestoreSpecificMainQuery.toSparql | ||
| log.debug(triplestoreSpecificMainQuerySparql) |
| * @param namedGraph the named graph to be used in the query. | ||
| */ | ||
| case class FromClause(namedGraph: IriRef) extends SparqlGenerator { | ||
| override def toSparql: String = s"FROM ${namedGraph.toSparql}\n" |
There was a problem hiding this comment.
we have a named graph here, shouldn't we use FROM NAMED? Or are you using FROM because the namedGraph is anyway the default graph? In that case, please rename the nameGraph to defaultGraph.
There was a problem hiding this comment.
Sorry, this is confusing. For me, any graph in the triplestore that has a name is a "named graph". The pseudo-graph <http://www.ontotext.com/explicit> is a "named graph" in that sense:
I've clarified this in a7f3a1c.
https://dasch.myjetbrains.com/youtrack/issue/DSP-534
AbstractPrequeryGenerator, parseknora-api:GravsearchOptions knora-api:useInferencewith a boolean object.knora-api:GravsearchOptionsandknora-api:useInferencein type inspection.SparqlTransformer, if that option is set, change the way the generated prequery is processed:FROM <http://www.ontotext.com/explicit>.