Ivan,
Thanks for your thorough explanation.
I understand the limitations of including procedures as relations and
now I see that it could indeed lend itself for costly situations and
it is therefore not something to take lightly. But I hope to see more
on this as my requirements and expectations on SPARQL grow each day.
Now, here's a funny question ( which is a very naive and specific
usecase for the above ). If I want to call a procedure via SPARQL HTTP
I can do the following:
select (sql:fullname( ?person ) ) as ?fname where { ?person a foaf:Person }
But what if I want to fix ?person to a given URI ?
Today, I need to do something like the following I guess
select (sql:fullname( ?person ) ) as ?fname where { ?person ?p ?o .
filter( ?person = <urn:someperson> ) }
instead of
select (sql:fullname( <urn:someperson> ) ) as ?fname
Are there any hidden tricks in the HTTP SPARQL toolbox to achieve this?
Regards,
A
On Thu, Jun 17, 2010 at 6:05 PM, Ivan Mikhailov
<[email protected]> wrote:
> Hello Aldo,
>
> That's technically possible but the compilation may seriously differ
> from expectations of an average developer.
>
> The problem is that SQL is not a procedural language, but people tend to
> write with some left-to-right order in mind, probably because they're
> writing it in that direction. Magic predicate collide with this
> illusion :)
>
> Consider
>
> sparql select * where { <urn:someperson> sql:fullname ?fullname .
> ?note <resulrce> ?fullname .
> ?note <text> ?note_text .
> }
>
> It will become, internally,
>
> sparql select (sql:fullname(<urn:someperson>)) as ?fullname,
> ?note ?note_text
> where { <urn:someperson> sql:fullname ?fullname .
> ?note <resource> `sql:fullname(<urn:someperson>)` .
> ?note <text> ?note_text .
> }
>
> That in turn will become
>
> sparql select (sql:fullname(<urn:someperson>)) as ?fullname,
> ?note ?note_text
> where { <urn:someperson> sql:fullname ?fullname .
> ?note <resource> ?tmp .
> ?note <text> ?note_text .
> filter (?tmp = sql:fullname(<urn:someperson>))
> }
>
> Looks bad but the optimizer will make something meaningful. However that
> will cause funny issues if ?fullname is used as an argument to next
> magic predicate --- the longer chain the longer the expression at each
> replacement.
>
> What's really bad is
> { ?X special-predicate-1 ?val . ?Y special-predicate-2 ?val }
>
> It masquerades the fact of full table scan. It looks like a plain join,
> but it is as inefficient as Cartesian product of values X and Y with
> non-optimizable filter (special-predicate-1(?X) =
> special-predicate-2(?Y)).
>
>
> I'd say that magic predicates will be useful if predicate is declared as
> a function and its inverse. In that case the filter could become
>
> (special-predicate-1(?X) = special-predicate-2(?Y))
> or
> (?X = special-predicate-1-INVERSE (special-predicate-2(?Y)))
> or
> (special-predicate-2-INVERSE(special-predicate-1(?X)) = ?Y)
>
> depending on optimizer's decision.
>
> I guess that this feature can be implemented not earlier than good
> support of arbitrary inverse functions in the SQL optimizer. So this is
> definitely not for Virtuoso 6.2, but maybe for some later release.
>
> Best Regards,
>
> Ivan Mikhailov
> OpenLink Software
> http://virtuoso.openlinksw.com
>
> On Thu, 2010-06-17 at 16:57 -0400, Aldo Bucchi wrote:
>> Hi,
>>
>> If I have the following procedure
>>
>> create procedure fullname( in uri varchar ) returns varchar {
>> for ( sparql select bif:concat( ?name, ' ', ?lastname ) as ?fullname
>> where { ?:uri foaf:name ?name ; foaf:lastName ?lastname } )
>> do { return fullname ; }
>> };
>>
>> I know I can do the following:
>>
>> sparql select (sql:fullname( ?person )) as ?fullname where { ... }
>>
>> But, any plans to implement the following way of calling the function?
>>
>> sparql select * where { <urn:someperson> sql:fullname ?fullname }
>>
>> Regards,
>> A
>>
>
>
>
--
Aldo Bucchi
@aldonline
skype:aldo.bucchi
http://aldobucchi.com/
PRIVILEGED AND CONFIDENTIAL INFORMATION
This message is only for the use of the individual or entity to which it is
addressed and may contain information that is privileged and confidential. If
you are not the intended recipient, please do not distribute or copy this
communication, by e-mail or otherwise. Instead, please notify us immediately by
return e-mail.
