Hi Hasan,
this is the query on which I was working:
PREFIX mo:
<http://www.tech-it-easy-project.eu/ontologies/market_ontology.owl#>
PREFIX list: <http://jena.hpl.hp.com/ARQ/list#>
PREFIX owl: <http://www.w3.org/2002/07/owl#>
PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
PREFIX dc: <http://purl.org/dc/elements/1.1/>
SELECT ?property ?range ?property_description ?subproperty
?subproperty_description
WHERE {
?property a owl:ObjectProperty .
FILTER (?property != owl:bottomObjectProperty) .
{
{
?property rdfs:domain ?superclass .
mo:Company rdfs:subClassOf ?superclass .
}
UNION
{
?property rdfs:domain ?dunion .
?dunion owl:unionOf ?dlist .
?dlist list:member ?superclass .
mo:Company rdfs:subClassOf ?superclass .
}
}
{
{
?property rdfs:range ?superrange .
?range rdfs:subClassOf ?superrange .
FILTER (!isBlank(?range)) .
}
UNION
{
?property rdfs:range ?range .
FILTER (!isBlank(?range)) .
}
} .
FILTER (?range != owl:Nothing) .
OPTIONAL { ?somesub rdfs:subClassOf ?range . FILTER(?somesub !=
owl:Nothing && ?somesub != ?range)}
FILTER (!bound(?somesub)) .
OPTIONAL {
?subproperty rdfs:subPropertyOf ?property .
FILTER(?subproperty != owl:bottomObjectProperty && ?subproperty
!= ?property)
OPTIONAL { ?subproperty dc:description ?subproperty_description . }
}
OPTIONAL { ?property dc:description ?property_description . }
}
Il 03/12/2012 07:53, Hasan Hasan ha scritto:
Hi Giuseppe
can you please provide an example of the query that you use and that I can
reproduce easily?
I will try to take some time this week to have a look.
Kind regards
Hasan
On Fri, Nov 30, 2012 at 5:36 PM, Giuseppe Miscione <
g.misci...@innovationengineering.eu> wrote:
Hi all,
I found a bug in the SPARQL query execution chain, specifically in the
*org.apache.clerezza.rdf.core.**sparql.query.Query* objects serialization
made with the
*org.apache.clerezza.rdf.core.**sparql.query.impl.**SimpleStringQuerySerializer*
methods.
The problem comes from the fact that the javacc objects used for mapping
triple patterns are not listed in the same order as in the original query
string. *SimpleStringQuerySerializer* serializes patterns into the ouput
string in the order returned by the javacc parser, and so the output string
won't always be equivalent to the source one. Moreover, parsing multiple
times the same query string will result in different output strings.
This problem is even more annoying when executing (like in my case)
queries on graphs enanched with Pellet reasoner, because it has obviuos
difficulties in inferencing relations if the order of triple patterns in
the query is not the provided one.
I solved the problem in my environment by simply saving the original
string into the parsed *Query *object and then making
*SimpleStringQuerySerializer* returns this string, without any processing.
Can anyone take a look at the serializer to find a maybe better solution
to avoid this weird behaviour?
Regards,
Giuseppe Miscione
