[tmql-wg] Toma - Use Cases Solution

[Rani Pinchuk]

Hi Robert,

Thanks for this extremely deep examination of Toma. One thing that is
true for sure, is that Toma is not mature enough - I just didn't have
yet enough time to work on it or on its implementation. But it serves us
quite well as a prototype for a project we are busy with. So I guess it
is not all dark...

Anyway, I will try to answer your questions below.

> instanceOf relationship - type()
> 
> I find the level for this operator not a very good idea.  I think that
> instance_of relationships themselves may be more or less robust
> against minor changes in the ontology for a map, but
> subclass-superclass relationships are rather brittle.
> 
> If we allow queries to use too much of this information, then queries
> are VERY dependent on these relationships. One day level=1 will work,
> next day it must be level=2.
> 
> What exactly does
> 
>    sometopic.type(1)
> 
> return? A list of topic which are the classes?
> 
> Does
> 
>    sometopic.type(*)
> 
> return the sometopic as well?
As I understood, the recommended usage of instanceOf is to declare an
instance of a class. If so, then only type(1) should be used. However, I
saw that sometimes, people use instanceOf for describing a hierarchy
(and XTM supports it after all). So this is why you find in Toma
type(2), type(*) etc.

Just to clarify:

$topic.type(0) is the same as $topic.  

$topic.type(1) is the class of $topic.

$topic.type(2) is the class of the class of $topic (whatever that means)

$topic.type(0..2) is $topic or the class of $topic or the class of the
class of $topic.

$topic.type(*) is like $topic.type(0..X) where X is infinite.

Note that I have included in the future/missing section the operator
super() which behave the same as type() but works with the association 
supperclass-subclass as defined in
http://www.topicmaps.org/xtm/index.html#psi-superclass-subclass

> Why cannot a topic be an instance of something and that something is
> an instance of something else?
Toma description doesn't block that possibility at all in my opinion.
But maybe I missed something...

> Associations
> 
>   How can 'city' be an association? Or even an association type?

I am not sure I understand the context of this question. Can you
explain?

> Is this equivalent?
> 
>    sender.id = 'motherboard'
>    sender    = motherboard
Yes. They are both syntax errors :-)

I guess you meant:
$sender.id = 'motherboard'
$sender    = $motherboard

$x represents ALWAYS a topic object. $x.id is the id of that topic
object, and it is a string. You can compare $x.id to a string. You can
compare $x to other topic object (which means that the two variables
will hold the very same topic object). 

> Chaining assocs:
> 
>    It says in the spec:
> 
>       This confusion is solved by the chaining rule: Any association
>       expression in a statement that has the same topic id or topic
>       variable as the association type share the same association
>       object.
> 
>    I find this rather brittle and a source for confusion. What if I do
>    NOT want to refer to the same assoc item in the map? Do I have to
>    introduce a fake condition in between?

I am still looking for ideas from the side of all of you. I am well
aware the syntax is problematic. But it has also big advantages IMHO.

$a@$s->$r is an expression that represents a topic object which plays
the $r role in the $a association type in the $s scope. 

In that expression you can change each of the topic objects with a
specific id of topic:

$a->whole represents all the players that plays the 'whole' role in
whatever association $a. 

But you can also put constrain on $a:

    $a->whole = $topic
and $a.id = 'part-whole'

is equivalent to

    part-whole->whole = $topic;

But if I need to have two DIFFERENT association objects of the SAME
type, I have to use the trick described in the chaining rule:

    part-whole->whole = $topic1
and part-whole->part = $topic2
and $a->whole = $topic2
and $a->part = $topic3
and $a.id = 'part-whole'

or even:

    $a->whole = $topic1
and $a->part = $topic2
and $a.id = 'part-whole'
and $b->whole = $topic2
and $b->part = $topic3
and $b.id = 'part-whole'

I will appreciate ideas of how to solve this chaining problem in a more
elegant way.



> Association Object Operator - %
> 
>    A special operator only to be used for a particular purpose... not
>    extremely orthogonal feature. And it returns numbers.
:-) Totally true. But I think XTM should take part of the blame :-)
Associations are objects so we have to somehow represents them. If
association was a topic object it would be a lot easier here. 
It returns IDs which can be whatever you choose (well, strings or
numbers). The idea is to be able to group the result sets by the
association objects. Like the chaining rule, I also see the problems
with this operator, but I could not find a better solution to represent
associations. I think one of the nice things in Toma is that $x
represents ALWAYS a topic object. If you have more elegant alternatives
please tell me about it.

>    This looks like the & address operator in C to me.
> 
>    Why cannot it be used with topics? Or basenames? It is sort-of a an
>    item reference operator. And what exactly is the output of
> 
>        %thermal-exchange
> 
>    All association objects of this type? Or only one which is
>    currently SELECTed?
The % operator should be understood in the context of the chaining rule.
Every time we select associations, we actually have behind the scene
association objects. Toma cannot represents those. I don't see any
reason to access them (because you usually access associations by their
types). But in order to show the following results set, you have to have
association object id so you can see which players are actually
associated:

 select %$association, $player, $role, $association
                 where $association@thermal->$role = $player;
 
  %$association |  $player    | $role  |  $association   
 ---------------+-------------+--------+-----------------
  24            | processor   | source | thermal-exchange
  24            | ventilator1 | sink   | thermal-exchange
  28            | ventilator2 | sink   | thermal-exchange
  28            | video-card  | source | thermal-exchange
 (4 rows)


> Scoping
> 
>    In the expression
> 
>        $person.oc@$scope.type(1)
> 
>    the precendence is a bit strange:
> 
>       - $person.oc binds stronger than oc@$scope, obviously
>       - but $person.oc @ $scope binds stronger than $scope.type(1)
> 
>    So the '.' has different strengths depending on its use. Or is
>    the processing strictly left-associate, i.e. postfix?
True! Very good point. Could I sat that the '.' by itself is no
operator? So it has no precedence all by itself? 
Indeed the scope binds stronger then anything else. 

But the precedences are a bit confusing. 

Other things that might be confusing in Toma is the question why the
following is not OK:

$a->$r->$r2 

This could be the player who plays the role $r2 in the association type
$a->$r. Currently Toma does not support this because I found it too
confusing. But then the -> operator does not behave like a "real"
operator... Ideas?

>       
> USE statement
> 
>    Does the statement
> 
>       use topicmap1, topicmap2;
> 
>    that the maps are merged?
> 
>    Why is that statement here other than as a default for the FROM clause?
? It is exactly a default for the FROM clause. If no 'use' statement is
used, all the selects should have FROM. The idea here is that the topic
maps are indeed merged. 

> 
> SELECT statement
> 
>    What does it mean to have two SELECT statements:
> 
>      use topicmap1;
> 
>      SELECT ....;
>      SELECT ....;
I am not sure I understood this one. Can you explain?

> SELECT clause
> 
>    Why should it not be possible to use the -> operator in the SELECT/return
>    clause:
> 
>       SELECT $assoc -> location, $assoc -> event FROM ...
True. It should be included. Currently the rule is not to introduce new 
variables ($something) in the SELECT clause, But maybe this should be
examined as well so the following is possible:

 select $topic.bn@scope, $scope where $topic in (...);

>       "Currently it is possible to retrieve the data only as strings.
The emphasis here is on 'Currently' :-) 

As this is the first language I try to define, and I am working quite
alone (apart of great emails like yours), and with time constrains, I am
quite afraid to include features without test them first (which is a big
drawback in the process obviously). This is why the "missing/future
features" section got so big... 

But when coming to solve the use cases, I had to use the features from
that section anyway, so I plan soon to include them in the main part of
the document. 


>    You say:
> 
>       "Any expression that returns a topic will be presented by its id."
> 
>    I guess you mean that any expression which returns a [topic item] will make
>    that value be coerced into the topic id if the context is the SELECT clause.
Yes. 

> 
>    You say:
> 
>       select $topic.bn where $topic.bn = 'is in';
> 
>    Does the $topic.bn mean the same thing here? Inside the WHERE clause
>    the interpretation is usually existential, i.e. there must be at least one to
>    satisfy the condition. In the SELECT it is usually extensional,
>    i.e. all interpretations should be chosen.
> 
>    I think there is no way around this looking sometimes funny.
True. 

If you have a topic 'in' with three base names and one is 'is in', then
$topic will hold this topic, and you will get the three basenames.

This is why returning of strings gave me such a headache :-) 

But I don't see a better way to do it then this. Ideas?

> 
> Comparison clause
> 
> 
>    You say:
> 
>       "If the two expressions around the equal sign are equal to each
>       other, the clause is evaluated to be true."
> 
>    Isn't it the case that you use unification (or at least matching)
>    to bind variables? Like in
> 
>       $topic1.type(1) = $topic2
I am not sure I understand your question. Can you explain?

>    You say:
> 
>       "If the two expressions around the non-equal sign are different
>       from each other, the clause is evaluated to be true."
> 
>    If you have
> 
>       in-location->container.id != 'case'
> 
>    does this now mean that you select all assocs of type 'in-location'
>    which have a 'container' role and check whether all players of this
>    role are NOT 'case'? Is it a
> 
>      "not some roles satisfy it"
>      "there is one which does not satisfy it"
> 
>    How can I control the two cases? We have cases
> 
>      "not one satisfies it"  (the same as "all do not satisfy it")
>      "at least one satisfies it"
>      "all satisfy it"
I cannot find a third example to this:

in-location->container.id = 'case' means that we select all associations
                                   that have at least one player that
                                   plays that role. 

in-location->container.id != 'case' means the inverse of the above. So
                                    all the associations of that type
                                    that have no player of that id
                                    playing that role 


>    Can the comparison operator also work on [topic items] and [assoc
>    items]?
Topic objects (mmm... I call them objects...) - yes.
Association objects - no. Can you give example when it is needed?

>    Can I have nested queries?
Well, yes. Similar to SQL. You have several examples in the solutions to
the use cases.

> All the topics that their base name has certain scope
> 
>   select $topic, $scope where exists $topic.bn@$scope and exists $scope;
> 
> How can this be that there exists a basename in a particular scope and
> the scope itself is not in the map? The map looks quite inconsistent
> to me.
? Which map do we speak about?

Maybe this will clarify it (if I understood the question): 
In 
  select $topic, $scope where exists $topic.bn@$scope;

$scope might be NULL (but $topic.bn@$scope must exists). 

In 
  select $topic, $scope where exists $topic.bn@$scope and exists $scope;
$scope cannot be NULL.

> All the topics with their base names and scopes (which can be NULL)
> 
>    select $topic, $scope where exists $topic.bn@$scope;
> 
> How can a scope be null? As I understood the (admittedly unnecessary
> complex) model a basename (or other things) are ALWAYS in a
> scope. Maybe it is the unconstrained scope, but they are in a scope.
Ah! This indeed simplify things for me :-) I take a scope as NULL if it
is not defined in the XTM. In the use cases solutions however, I defined
all the "NULL" scopes to be "uc" (according to what I understood from
the documentation of the use cases). 

> As above, does A.type(2) = B mean
> 
>   "A is instance of C and C is instance of B"
>   "A is instance of C and B is superclass of C"
>   "A is subclass of C and C is subclass of B"
I hope it was cleared above. $a.type(2) = $b means that $a is instance
of $c and $c is an instance of $b.

> Is there also the inverse operator type(-1) ?
I didn't think about it! Should we have it? We could always write 
$a.type(-1) = $b as $a = $b.type(1). Will be happy to read your opinion.

> All the topics that have resourceRef occurrences, and that those occurrences have also a scope
> 
>    select $topic, $oc_type, $scope where exists $topic.oc($oc_type)@$scope.rr;
> 
> What happens here if one of the occurrences does have an empty scope or
> an empty type? Is the occurrence still counted in?
:-) with that "yuck, argh" and "yack^2" - $scope and $type might be
NULLs :-) So unless you write:

  ... and exists $oc_type and exists $scope

you might get NULLs in the result set.

==========

Robert, Thanks again for your very interesting and challenging questions
- I hope at least most of my answers make some sense. I will be looking
forward for you feedback.

Rani

--