incubator-clerezza-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Giuseppe Miscione <g.misci...@innovationengineering.eu>
Subject Re: Bug in SPARQL query serialization
Date Mon, 03 Dec 2012 14:13:34 GMT
Hi Hasan,
I prepared a JUnit test method that clarifies the problem:

@Test
public void testParseMultipleTimes() throws Exception {
     String queryString =
         "PREFIX mo: 
<http://www.tech-it-easy-project.eu/ontologies/market_ontology.owl#>\n" +
         "PREFIX list: <http://jena.hpl.hp.com/ARQ/list#>\n" +
         "PREFIX owl: <http://www.w3.org/2002/07/owl#>\n" +
         "PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>\n" +
         "PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>\n" +
         "PREFIX dc: <http://purl.org/dc/elements/1.1/>\n" +
         "SELECT ?property ?range ?property_description ?subproperty 
?subproperty_description\n" +
         "WHERE {\n" +
         "    ?property a owl:ObjectProperty .\n" +
         "    FILTER (?property != owl:bottomObjectProperty) .\n" +
         "    {\n" +
         "        {\n" +
         "            ?property rdfs:domain ?superclass .\n" +
         "            mo:Company rdfs:subClassOf ?superclass .\n" +
         "        }\n" +
         "        UNION\n" +
         "        {\n" +
         "            ?property rdfs:domain ?dunion .\n" +
         "            ?dunion owl:unionOf ?dlist .\n" +
         "            ?dlist list:member ?superclass .\n" +
         "            mo:Company rdfs:subClassOf ?superclass .\n" +
         "        }\n" +
         "    }\n" +
         "    {\n" +
         "        {\n" +
         "            ?property rdfs:range ?superrange .\n" +
         "            ?range rdfs:subClassOf ?superrange .\n" +
         "            FILTER (!isBlank(?range)) .\n" +
         "        }\n" +
         "        UNION\n" +
         "        {\n" +
         "            ?property rdfs:range ?range .\n" +
         "            FILTER (!isBlank(?range)) .\n" +
         "        }\n" +
         "    } .\n" +
         "    FILTER (?range != owl:Nothing) .\n" +
         "    OPTIONAL { ?somesub rdfs:subClassOf ?range . 
FILTER(?somesub != owl:Nothing && ?somesub != ?range)}\n" +
         "    FILTER (!bound(?somesub)) .\n" +
         "    OPTIONAL {\n" +
         "        ?subproperty rdfs:subPropertyOf ?property .\n" +
         "        FILTER(?subproperty != owl:bottomObjectProperty && 
?subproperty != ?property)\n" +
         "        OPTIONAL { ?subproperty dc:description 
?subproperty_description . }\n" +
         "    }\n" +
         "    OPTIONAL { ?property dc:description ?property_description 
. }\n" +
         "} ";

     Query query1 = QueryParser.getInstance().parse(queryString);
     System.out.println(query1.toString());

     System.out.println("-----------------------");

     Thread.sleep(5000l);

     Query query2 = QueryParser.getInstance().parse(queryString);
     System.out.println(query2.toString());

     Assert.assertEquals(query1.toString(), query2.toString());
}

By separating the two parse() calls with a 5 seconds sleep, you'll see 
that the two parsed objects will produce different strings. Without the 
Thread.sleep() call the test method doesn't fail, so I think there's 
something time-related in the javacc parser that will mix up the parsed 
statements.

Regards,
Giuseppe

Il 03/12/2012 10:25, Giuseppe Miscione ha scritto:
> 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.miscione@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
>>>
>>>
>


Mime
View raw message