Re: FYI: TMQL - New slides

On Fri, Apr 01, 2011 at 11:42:17AM +0200, Benjamin Bock wrote:
> Hi Robert,
> 
> On Fri, Mar 25, 2011 at 8:45 PM, Robert Barta <[email protected]> wrote:
> > Hi Rani et.al.,
> >
> > Is it intentional that typing for assocs and for topics is treated
> > differently? For assocs (eg. Slide 15)
> >
> >   t1 / typed
> >
> > For topics (Slide 52):
> >
> >   t1 / instances
> 
> Yes this is intentional for the following reasons:
> We want instances to return only topics, not any other constructs by
> default. While returning other constructs could be enabled e.g. by a
> parameter, we decided to have two separate axes for that.

So the original criticism of TMQL@rho was: "too many axes!".

And you counter this with even more ones? Not only by giving every
direction an axis, but also distinguish between topic/assoc axes?

Whuff. You guys definitely know how to alienate everyone :)))

> > I know that TMDM hold the "data type" within the occurrence node
> >
> >   http://www.isotopicmaps.org/sam/sam-model/#sect-occurrence
> >
> > [yes, weirder things have happened], but TMDM also assumes that values
> > are all strings.
> >
> > As this cannot be the case for TMQL (it has to be able to apply numeric
> > operators), why is this maintained in Slide 21ff ?
> 
> The datatype axis is provided to enable access to anything which is
> available in a TMDM topic map.
> The value axes returns objects in their original datatype. We consider
> something oc1 / value(xsd:string) or string(oc1 / value) to return
> objects converted to another datatype (string in this case).

So this would be

   bb / homepage / value(xsd:anyuri)

compared to TMQL@rho

   bb / homepage

??

> > On slide 65 filtering is introduced using []. But throughout the
> > earlier slides an implicit filtering is always provided inside ():
> >
> >  t1 / occurrences(address)
> 
> This is similar to t1 >> characteristics address in your draft.

Not really. "address" is NOT a filter, i.e. it is NEVER the case that
ANYTHING not being an "address" is considered. Filters operate on
wholeset sequences and post-mortem remove non-matching elements.

Again, this is all about speed: In

   bb >> occurrence homepage

I am ONLY looking for "homepage" occurrences, i.e. any multi-level
index on occurrences you might have can immediately be effective in
returning the correct results. No further filtering necessary.

> > Slide 72: in
> >
> >  // topics(composer)
> >
> > what exactly is the relevance of // ? Would not
> >
> >  topics(composer)
> 
> It's
> 
> / instances(composer)
> 
> now or just
> 
> / composer
> 
> We removed the // everywhere and the topics axis is called instances now.

I guess I'll wait to comment on that until someone has ventured to
write the grammar for it.

> > Slide 72: Are these ops REALLY meant to be SET operations? I hope you
> > understand the relevance of that question in respect to performance.
> 
> You mean compared to bag operations? Otherwise: no. Hints?

A set is something where every element only occurs once. That is the
contractual agreement with the observer. For the software it means
that it has to guarantee the set that after every operation. For large
sets, this can be a _VERY EXPENSIVE_ operation.

This is the reasons why many systems prefer (XSLT, XQuery, RDFS) to
use (unsorted) sequences (aka bags). Here it is up to the user to
decide on uniqueness (DISTINCT) or on order (ORDER BY).

> > I am also - amused ;-) by the reemergence of functions aka
> > user-defined axes. The world is indeed a round thing....
> 
> Can you provide resources/links where to learn from history?

Once upon a time, one could write this in TMQL@rho:

   bad-bad-people isa tmql:function
   tmql:return
        // person [! . <-> liking == tmql ]

   FOR $p IN bad-bad-people()
   WHERE
        $p isa sc34-member
   RETURN
        $p / name

I have quite some traumatic memories, not about the rejection itself,
but about the verocity thereof.

> > Slide 78, lower half: I would love to see a 'formal', complete
> > definition of this. I suspect that you will encounter quite some
> > rather counter-intuitive effects:
> >
> >  select $topic / shoesize, $topic / birthdate
> >  from $topic / type = very-weird-person
> >
> > may give you 4 results with 2 birth-dates and 2 shoesizes.
> >
> > Delete the shoesizes and the query never returns you something.
> >
> > OTOH
> >
> >  select $topic / shoesize, $topic
> >  from $topic / type = very-weird-person
> >
> > will give you always one result per weird person.
> >
> > ------
> >
> > Slide 79: Also here I would like to see a more comprehensive
> > description what it means to have unbound variables inside the SELECT
> > clause.
> 
> We didn't work on select yet and will put these two inputs on our
> need-to-investigate list.

This is a place of non-continuity. It maybe meant to "support" the
naive user to avoid him (probably her ;-) to see no results. Some call
this design the "nanny-mode". Very popular in Europe where the
government knows what is best for you. The overall state of Europe
shows how good this works. ;-)

\rho