Hi Olaf,

OK this explains it. In this case, please adjust the following function in 
SPINFactory with the extra check to exclude sp:Variable as shown below. I am 
including this change in the next release as well (my tests still pass).

I honestly didn't expect anyone to generate SPIN RDF by hand (or with some 
other algorithm than the provided SPIN parser), so I may not have tested those 
cases. What you did was perfectly valid according to the spec though. If you 
have a minute I would be very interested to hear about your use case of the API 
in your project (maybe off-list).

Viele Gruesse
Holger


        public static FunctionCall asFunctionCall(Resource resource) {
                if(resource.isAnon()) {
                        Statement s = resource.getProperty(RDF.type);
                        if(s != null && s.getObject().isURIResource() && 
!SP.Variable.equals(s.getObject())) {
                                return resource.as(FunctionCall.class);
                        }
                }
            return null;
        }




On Sep 16, 2010, at 8:43 PM, Olaf Hartig wrote:

> Hey Holger,
> 
> Yes, it's true. In my system all the blank nodes that represent query 
> variables have the rdf:type sp:Variable statement. Hence, the example in my 
> bug report was incomplete. Sorry.
> However, now I see that exactly this statement seems to be the cause of the 
> problem. Due to this statement the 'asFunctionCall' method incorrectly 
> assumes 
> the blank node for the variable is a function call and, thus, the cast in 
> 'printOrderByExpression' works, which shouldn't. Therefore, the solution to 
> try to cast to a Variable before trying to cast to a FunctionCall as I 
> propose 
> in my report still seems to be suitable.
> 
> Greetings,
> Olaf
> 
> On Thursday 16 September 2010 11:21:45 Holger Knublauch wrote:
>> Hi Olaf,
>> 
>> I have been trying to reproduce this, but so far without success. Judging
>> from the source code, the variable blank node would have to have an
>> rdf:type while your example below does not have this. You can also try
>> that this works in general if you just enter this with TBC (FE) on some
>> resource for property spin:query (or define a corresponding Template
>> there).
>> 
>> So I may need a more complete test case. I did notice though that if the
>> rdf:type is sp:Variable, then the existing code might indeed be wrong. But
>> the parser usually does not create this triple, so I don't think this is
>> the issue.
>> 
>> Thanks,
>> Holger
>> 
>> On Sep 16, 2010, at 7:47 PM, Olaf Hartig wrote:
>>> Hello,
>>> 
>>> There is a problem in the SPIN API with printing an ORDER BY expression
>>> that contains a query variable.
>>> 
>>> Let's say I have the following SPIN description of a SPARQL query with an
>>> ORDER BY clause:
>>> 
>>> _:myQuery
>>> 
>>>        rdf:type sp:Select ;
>>>        # ...
>>>        sp:orderBy ( [sp:varName "dep"^^xsd:string] ) .
>>> 
>>> When I print this query with the SPIN API using the class
>>> 'StringPrintContext' I would expect to get something like:
>>> 
>>> SELECT ... {
>>> ...
>>> }
>>> ORDER BY ?dep
>>> 
>>> but what I get is
>>> 
>>> SELECT ... {
>>> ...
>>> }
>>> ORDER BY (sp:Variable())
>>> 
>>> I tried to track this problem down. It seems to be in the method
>>> 'printOrderByExpression' of class 'QueryImpl'. This method is called with
>>> a Resource which is of rdf:type sp:Variable and it represents the
>>> variable. The first thing 'printOrderByExpression' with this Resource,
>>> it tries to cast it to a 'FunctionCall' which works. Therefore, it tries
>>> to print the variable as if it were a 'FunctionCall'.
>>> I think this problem can be fixed by trying to cast the Resource to a
>>> 'Variable' before casting it to a 'FunctionCall' and if it turns out to
>>> be a a variable (i.e. if the cast works) then use the functionality to
>>> print variables.
>>> 
>>> Greetings,
>>> Olaf
>>> 
>>> ----------------------
>>> Olaf Hartig (http://olafhartig.de)
>>> 
>>>  Database and Information Systems Research Group
>>>  Department of Computer Science
>>>  Humboldt-Universität zu Berlin
> 
> -- 
> You received this message because you are subscribed to the Google
> Group "TopBraid Suite Users", the topics of which include TopBraid Composer,
> TopBraid Live, TopBraid Ensemble, SPARQLMotion and SPIN.
> To post to this group, send email to
> [email protected]
> To unsubscribe from this group, send email to
> [email protected]
> For more options, visit this group at
> http://groups.google.com/group/topbraid-users?hl=en

-- 
You received this message because you are subscribed to the Google
Group "TopBraid Suite Users", the topics of which include TopBraid Composer,
TopBraid Live, TopBraid Ensemble, SPARQLMotion and SPIN.
To post to this group, send email to
[email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/topbraid-users?hl=en

Reply via email to