[tmql-wg] TMQL, next round

[Robert Barta]

On Tue, Mar 06, 2007 at 11:31:45AM +0100, Gabriel Hopmans wrote:
> Before you are going to talk too much too yourself and listing the issues
> one by one..

Well, I do not have a problem with talking with myself. I even mostly
agree with myself these days ....

> ..... For instance a SUMMATION function on financial data is very
> essential. Customers need to see the ROI of Topic Maps :)

I do not know what you refer to as 'financial data', but as far as normal
addition is involved, then

   http://www.w3.org/TR/xpath-functions/#aggregate-functions

over sequences definitely make sense to me.

> The only question is then which pretty basic functions and predicates do we
> need and which one are more typically in the direction of an 'ontology
> definition language'.

Yeah, someones 'basic' is another one's 'advanced'. Whatever we do here, it
will be wrong. People call this a 'tradeoff' :-))

> By the way very cool work on TMQL and impressive issue list.. lot of high
> impacts ;)

Well, at least there is a choice there. But even if nothing were
decided in the issues list, TMQL is fully functional as it stands. So
the issues list is an option to make it better. Or worse ;-)

\rho

> Issue 2 is:
> 
> TMQL Issue: TM paradigmatic functions, predicates, templates, ontologies
> Impact on Language: very high
> 
> Background
> TMQL uses the TM paradigm not hypocritically in that it offers querying of
> data according to the TM paradigm; TMQL also
> tries to exploit the paradigm for language features which are traditionally
> not seen as topic-mappish.
> In this sense language constructs such as functions, predicates, but also
> namespace prefixes are interpreted as subjects,
> represented in a map by topics of certain predefined TMQL types, such as
> tmql:function.
> A function is a systematic functional dependency over particular sets of
> values. The age of a person is functionally
> dependent on (a) the person's birthdate and (b) the current time.
> Similarily, a predicate is a constraint on a constellation of
> particular values.
> Accordingly, both are expressing additional knowledge about a problem
> domain. As the modelling of an application domain
> is usually done via an ontology definition language, one can argue that
> functions and predicates should NOT be part of
> TMQL, which is meants as a data access language.
> Structured Discussion
> ? Should Functions and Predicates be included into TMQL
> - both are ontological information, should go into an ontology language
> - yes, but TMCL will not offer them, neither does CTM, ...
> + they are EXTREMELY useful to organize the query, uhm knowledge
> - SPARQL does not have function declarations or predicate declarations
> 
> 
> On 2/26/07, Robert Barta <rho at bigpond.net.au> wrote:
> >
> >Hi all,
> >
> >You may have noticed that the latest TMQL draft was submitted
> >recently
> >