TAKE 1.5 released

[jens]

We have just release a new version of TAKE. It contains a totally new
scripting framework. Conditions and terms can now use JSP expression
language syntax (similar to ECMAScript). The parser is handcrafted on
top of JUEL (an existing EL parser). Other changes:

- imports can be used in scripts – this is convenient for long package
names (in var or ref declarations)
- global annotations can be copied to become local annotations, an
annotation policy allows to specify this by key – this results in less
annotations

Some other news:
- Graham will release an Eclipse plugin to edit TAKE scripts later
this week
- Jens will present TAKE at the Australian Software Engineering
Conference in Perth later in March
- there is a new online presentation about TAKE:
http://docs.google.com/Presentation?id=dgzzp6gn_886zjtj2pt

[brigh...@gmail.com]

Dear Jens and Graham,

I installed TakeDT from http://take.googlecode.com/svn/trunk/TakeDTUpdate/,
but it couldn't work after eclipse restarted, and my eclipse is 3.2.2.
Is the TakeDT Graham released recently?

BTW, I want to use Take in our project, in which we'll process lots
of address strings and spatial data in PostGIS. I choosed Take after
comparing it with this long list: http://www.declarativa.com/interprolog/systems.htm,
because Take works seamlessly with Java. Great tool! Thanks.

On Feb 11, 9:40 am, jens <jens.dietr...@gmail.com> wrote:
> We have just release a new version of TAKE. It contains a totally new
> scripting framework. Conditions and terms can now use JSP expression
> language syntax (similar to ECMAScript). The parser is handcrafted on
> top of JUEL (an existing EL parser). Other changes:
>

> - imports can be used in scripts - this is convenient for long package

> names (in var or ref declarations)
> - global annotations can be copied to become local annotations, an

> annotation policy allows to specify this by key - this results in less

[Jens Dietrich]

Hi, you will need version 3.3. Graham - can you try to fix the prereqs in the feature description?

Let us know how the projects goes - and thanks for using TAKE!

Cheers, Jens

[brigh...@gmail.com]

Dear Jens,

I can run TakeDT under eclipse 3.3 now. Thank you.

We'd like to know the limitations of Take, but the section "21.
Limitations and Missing Features" of "The Take Manual" is blank.

We want to know the following aspects:
1. Stability. Is 1.5 Version a stable release? Is there any other
application or project using Take?
2. Efficiency. How about the space and time complexity if we have a
large fact bases (say, some millions of spatial objects and relations
between some of them used as facts)? Can I cache the frequently used
facts and load the ones rarely used from DBMS when needed.
3. Does Take have any serious limitations comparing with Prolog, now
that both of them use backword reasoning? I think that backword
reasoning is the right choice in our problem domain.

Best wishes!

On Mar 10, 6:24 pm, "Jens Dietrich" <jens.dietr...@gmail.com> wrote:
> Hi, you will need version 3.3. Graham - can you try to fix the prereqs in
> the feature description?
>
> Let us know how the projects goes - and thanks for using TAKE!
>
> Cheers, Jens
>

> On Mon, Mar 10, 2008 at 11:01 PM, brightp...@gmail.com <brightp...@gmail.com>

[Jens Dietrich]

Hi,

Reg limitations and difference to Prolog - cut is not supported and we don't intend to add support for cut. I guess the main limitation is that it is still relatively new software. However, there are plenty of test cases and stability is defined w.r.t. these test cases. Regarding expressiveness - TAKE is expressive enough to  represent the UServ benchmark. We also think TAKE is very scalable, but do not yet have benchmarks to prove our point. Perhaps other people using it could comment on this. Another limitation is that in kbs build from scripts integers are now always represented as long. This is due to the use of longs in the JSP-EL  language used. It is actually possible  to change this  (to int), but this is not documented. Ask me again if this becomes an issue.

The time complexity is essentially the standard complexity of depth first search (DFS), which is (O(|V| + |E|)) (V=vertices, E=edges). That is, it depends on the number of rules, facts and prerequisites of rules (vertices), and the links between rule prerequisites and facts/rule heads (edges). But I expect that in most scenarios the processing of facts (from large external fact stores) will be the performance bottle neck. Here, implementing the fact stores correctly is crucial. In particular: use caches when possible, and implement precise queries that use all parameters available (those are exactly the bound variables) to fetch exactly the facts you need (see http://take.googlecode.com/svn/trunk/take/src/test/nz/org/take/compiler/scenario8/FactStore.java for example).

Hope this helps, Jens