Hi
We've installed installed virtuoso 6.1. One of the new features on the list
is
Added support for expressions in LIMIT and OFFSET clauses
So we tried to write again this query inside of a for in a virtuoso
procedure.
sparql select distinct
?documentId ?title ?abstract ?title_relevance ?abstract_relevance
?classification
{graph ?:hostUri {
...
...
...
}} order by
desc((?title_relevance+?abstract_relevance)/2.0)
desc(?title_relevance/2.0)
desc(?abstract_relevance/2.0)
limit 50 offset ?:offsetValue
But we received this error message.
"Unable to use variable ?:offsetValue in OPTION () clause, try to rephrase
the query at"
which disappears when we replace ?:offsetValue by 0 or any integer.
We use others procedure variable into "for (sparql query) do ..." sentence
in the way we did for offset (?:<variable name>), in other contexts into the
expresion and works fine.
We are referencing the variable wrong?
Thanks.
Z.
On Sun, Jan 24, 2010 at 11:55 AM, Aldo Bucchi <aldo.buc...@gmail.com> wrote:
> Hi Ivan,
>
> On Thu, Jan 21, 2010 at 12:46 PM, Ivan Mikhailov
> <imikhai...@openlinksw.com> wrote:
> > Hello Aldo,
> >
> >> OK, and what about:
> >> [10]* DefaultGraphClause ::= SourceSelector SpongeOptionList?
> >> [11]* NamedGraphClause ::= 'NAMED' SourceSelector
> SpongeOptionList?
> >> ?
> >
> > That costs much more than an extension for LIMIT/OFFSET (that is
> > implemented already, right today). The reason is that any extension in
> > FROM/FROM NAMED interferes with graph-level security that is complicated
> > by itself and, more important, the debugging is complicated. While
> > other features should work when needed, security should prevent things
> > from working when unwanted; I'm an engineer, not a turnkey, so that sort
> > of thinking damage my brains in a quite unusual way :)
>
> I see.
> Now, there is always the option of implementing for the simple subset
> and then stating that this will bypass security, etc.
> But that's a bigger problem I guess.
> As an engineer, I also understand that when modifications compromise
> other (working) pieces of the system then they should be queued at
> least till there is a feature freeze.
> Otherwise you might be shooting yourself on the foot.
>
> >
> >> And, on a related note. The other low hanging fruit:
> >> i++; i+=3
> >
> > That's a long-waiting feature, I'm going to add it since 2001. However
> the accurate implementation of the feature should deal with UDT members as
> well, that requires some amount of coding. A trivial "macroexpansion"
> > like "i := i+1; i := i+3" does not work there, because functions inside
> "i" will be calculated twice.
>
> I could say that I understand ( because I do, in essence ), but I
> would be lying.
> In concrete terms.. which specific case?
>
> declare person PersonUDT;
> person := new PersonUDT();
>
> person.age++;
> -- or
> person.age += 1;
>
> -- would become
>
> person.age := person.age + 1;
>
> ??
>
> That's not the case I assume. But that's what I understand by a UDT
> "member".
>
> Now, a UDT "instance" case would be
>
> person +:= person;
>
> (I'm not sure what the latter should mean anyway ).
>
> And also, remember that one very common use case beyond +:= ( addition
> ) is ||:= ( concatenation ).
>
> Regards,
> A
>
> >
> > Best Regards,
> >
> > Ivan Mikhailov
> > OpenLink Software
> > http://virtuoso.openlinksw.com
> >
> >
> >
>
>
>
> --
> Aldo Bucchi
> skype:aldo.bucchi
> http://www.univrz.com/
> 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.
>
