On 11/11/13 09:36, Rob Vesse wrote:
Unless you've explicitly stored your data in named graphs using FROM and
FROM NAMED is not going to help you and will produce empty result sets as
you describe. Jena does not automatically partition your data for you,
this is a decision you have to make as a user of the API.
If you want to restrict your query as described and haven't stored your
data in named graphs then there is nothing much you can do to make the
query perform any faster without changing how you are storing your data.
Btw you haven't said what triple store you are using? Are you using the
ARQ in-memory store or are you using TDB? TDB should be substantially
more performant.
Rob
SungKu,
Rob is right about named graphs and, critically, the details of storage
and data.
There are some query changes that may help for TDB from Jena 2.7.2:
1/ Put
?LE a NS_TurbineBladeOntology:AirfoilWall .
?TE a NS_TurbineBladeOntology:AirfoilWall .
?CSS a NS_TurbineBladeOntology:AirfoilWall .
last.
Maybe also
?f a NS_TurbineBladeOntology:AirfoilWall .
2/ As this is an old verion, switching to the fixed.opt optimizer - then
you take control of the order in the query.
3/ You seem to be using the idiom
SELECT ... (COUNT(DISTINCT ?LE) AS ?NumberOfLE)
...
HAVING .. (?NumberOfLE = 1) ...
to determine if
?f NS_SpatialRelationOntology:isAftOf ?LE .
has a unique match.
There may be a faster way:
?f NS_SpatialRelationOntology:isAftOf ?LE .
FILTER NOT EXISTS {
?f NS_SpatialRelationOntology:isAftOf ?LE2 .
FILTER(?LE != LE2) }
(and the same for ?TE and ?CSS
This prunes the processing earilier.
Above all - you'll have to try out the different possibilities. There
isn't a definitive answer.
Andy
PS SPIN has been upgraded.
On 11/11/2013 06:16, "Kang, Sungku" <[email protected]> wrote:
Hello,
I'm using SPARQL update (using Ontology API of Jena 2.7.2, to make my
system compatible with SPIN API as well) for tagging instances
(classifying classes of instances)
and I found that some of my queries take too much time to complete.
To make them faster, I'd like to restrict the range of SPARQL queries.
For example, assuming '?f' are the instances to be retrieved, I'd like to
restrict that "?f belongs to a certain ontology, therefore the system
need not to search other ontologies for ?f".
The below is one example of my query.
--------------------------------------------------------------------------
-----------------------------------------------
PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
PREFIX owl: <http://www.w3.org/2002/07/owl#>
PREFIX NS_SpatialRelationOntology:
<http://sadl.org/SemTagOntology/SpatialRelationOntology#>
PREFIX NS_FeatureOntology:
<http://sadl.org/SemTagOntology/FeatureOntology#>
PREFIX NS_TurbineBladeOntology:
<http://sadl.org/SemTagOntology/TurbineBladeOntology#>
PREFIX NS_GenericTurbineBlade:
<http://sadl.org/SemTagOntology/GenericTurbineBlade#>
INSERT{
?f a NS_TurbineBladeOntology:ConcavePressureSurface
}
WHERE{
SELECT ?f (COUNT(DISTINCT ?LE) AS ?NumberOfLE) (COUNT(DISTINCT ?TE) AS
?NumberOfTE) (COUNT(DISTINCT ?CSS) AS ?NumberOfCSS) WHERE {
?f a NS_TurbineBladeOntology:AirfoilWall .
?LE a NS_TurbineBladeOntology:AirfoilWall .
?TE a NS_TurbineBladeOntology:AirfoilWall .
?CSS a NS_TurbineBladeOntology:AirfoilWall .
?f NS_SpatialRelationOntology:isAftOf ?LE .
?f NS_SpatialRelationOntology:isStarboardOf ?TE .
?f NS_SpatialRelationOntology:isPortOf ?CSS .
}
GROUP BY ?f
HAVING( (?NumberOfLE = 1) && (?NumberOfTE = 1) && (?NumberOfCSS = 1) )
}
--------------------------------------------------------------------------
--------------------------------------------------
I tried keyword "FROM ", "FROM NAMED", and "GRAPH" but I was not able to
specify the range of query.
(I was not able to make valid SPARQL query with "With" keyword)
More specifically, when I use the them, it seems like the query set
becomes empty.
(It cannot retrieve anything, and the execution time is extremely fast)
If someone have suggestion about the issue, please let me know.
I hope you have a nice day!
Regards,
SungKu
