Re: FYI: TMQL - New slides

Hi Robert,

On Sat, Apr 2, 2011 at 9:43 AM, Robert Barta <[email protected]> wrote:
> 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!".

Never heard that criticism about TMQL@rho before. Anybody else? Maybe
the critics can elaborate on that.
I remember mostly two things:
* people find the bidirectional axes confusing so we replaced them by
single-direction axes.
* people find the noncanonical level (aka short cuts) cryptic and too perlish.

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

At least we can work undisturbed if we're successful (-;

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

Well, if you're so crazy to store the homepage with a _different_
datatype than xsd:anyuri, you'll of course have to convert it upon
retrieval.
If you store the homepage as xsd:string and want to retrieve it as
string, you'd do:

    bb / homepage / value

. If you left out the "/ value", you'd get an occurrence object (as
JTM or XTM fragment or TMAPI object or whatever... depending on the
engine.

I didn't find where TMQL@rho does the automatic conversion xsd:string
to xsd:anyuri, though. What's the heuristics? If value =~
/web|homepage|url|uri/href/i ? Can you point me to it? Or can I just
assume you're looking for differences where there are none?

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

It works exactly as you describe it in the new draft, too. I guess
it's just the title of the slide which might be suboptimal and
confused you.
A kind reminder: We're taking TMQL@rho as the base for our work. :)
Obviously, we're still in the educational phase (for all parties).

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

Stay tuned :D
One reason why it works is that (currently) axes need parentheses
while de the default axis parameter don't allow them.

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

OK, so I consider this as a "yes". Thanks for confirming my thoughts.

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

Agreed. The new TMQL will join the above mentioned here, too.

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

Well, bad luck with your sc34-members then. All current members of sc
34 wg 3 (i.e. those who did attend the last meeting) are in favor of
user defined _axes_.
We don't have user defined functions (yet).

- Benjamin
_______________________________________________
topicmapmail mailing list
[email protected]
http://www.infoloom.com/mailman/listinfo/topicmapmail