Re: FYI: TMQL - New slides

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.

The search for an axis name to get all constructs typed by a topic
lead us to typed. We prefer it over typed_constructs, typed_objects,
construct_instances, reifiable_instances and some others. Alternative
namings are welcome as well as why and if the typed axis might not be
a good idea and proposals how to make it better.

> ------
>
> 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).

> ------
>
> 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. You
can still add a []-filter there, too.
Are you critizising your earlier work here? Any interim learnings
since 2008 are welcome (-;

You can also do

t1 / occurrences() [ . / type() = address ]

which is even more typing.

> Not to mention that this is more typing than
>
>  t1 / address

This should work via the default axis (which is names union
occurrences for topic).

> which we already had and where I do not remember many people had issue
> with. Or is this a shortcut I missed somewhere when I skimmed through
> the doc?

In these slides there's just the question if we want a default axis.
But it is in the new (and yet-to-be-published) ones.


> ------
>
> 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.

> or better
>
>  topics[composer]
>
> achieve the same?
>
> ------
>
> 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?

> ------
>
> 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?

> ------
>
> 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.

Best regards,
Benjamin

>
> \rho
> _______________________________________________
> topicmapmail mailing list
> [email protected]
> http://www.infoloom.com/mailman/listinfo/topicmapmail
>
_______________________________________________
topicmapmail mailing list
[email protected]
http://www.infoloom.com/mailman/listinfo/topicmapmail