[Mulgara-dev] SMF functions available

[Paul Gearon]

On Wed, May 30, 2012 at 10:31 AM, Agustina Martinez <amgcia at gmail.com> wrote:
> Hi Paul,
>
> No worries! Thanks for this, yes I am able to build it from source. Will try
> and let you know.
>
> On the other hand, I am now exploring Sparql 1.1. and I was wondering
> whether you were thinking on adding some of the new query functions from
> 1.1. anytime soon? What are your plans regarding Sparql 1.1.

<sheepish look>

Yeah, this should be done already. I made a start, then got
sidetracked. It's a bit embarrassing, given that I'm on the SPARQL
working group.

I need to write an entirely new JavaCC file for the new grammar. Once
that's done I can use an iterative approach to implementing full
SPARQL 1.1 functionality:

1) Copy over existing code to implement the existing SPARQL 1.0
functionality. Most of this will happen automatically with the
authoring of the new JavaCC file, since lots of bits will be copied
from the existing file.

2) Hook in Update operations, particularly INSERT and DELETE. These
are already in TQL, so most of the mechanism is there. At this stage
only very basic support will be provided, as it will be easy to get
sidetracked onto the protocol implementation here.

3) Attach new SPARQL 1.1 functionality to existing functionality in
the engine. This includes COUNT, and new functions. Some of these will
be trivial (especially the functions and bindings). Some will require
some tweaking, but are easy (eg. most of property paths). Others will
take more work (COUNT is currently configured to only work on
subqueries. Won't be too hard, but more work is involved). Since most
functions are trivial, I'll be doing them here even if a specific
function doesn't yet exist. Have a look in
src/jar/query/java/org/mulgara/query/xpath/ to see how much work it
takes to write a new function (very little).

4) Finish the Update operations, including protocol.

5) Implement new functionality. This will include the new aggregates,
the new functionality in property paths, service, values, and
subqueries. All of these will need extensions to the engine, but
nothing onerous. (The one exception might be counting on property
paths. Though I think that may be OK if I just use a naive approach)

The main impediment to this is that it has to happen when I'm not at
work, and my children want their "Daddy". They can be so inconsiderate
at times.  :-)

Alex, how about you? Any interest in this?

Paul