# [tmql-wg] Toma - Use Cases Solution

Robert Barta rho@bigpond.net.au
Sun, 14 Mar 2004 16:02:49 +1000

On Thu, Mar 11, 2004 at 02:08:13PM +0100, Rani Pinchuk wrote:
> During the effort of writing this solutions, I found all kind of
> features I should add/mention in the Toma description
> (http://www.spaceapplications.com/toma/Toma.html) so this file is also
> updated.

Rani,

Thanks for all this efforts, it helped me understand a lot how Toma
works. Following is a (random) list of thoughts and questions which I

\rho

==============================

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?

If the operator .type(n) is always used in a comparison, then a predicate
like

is_instance_of (A, B)

is probably better than

A.type = B

IMHO.

--

Why cannot a topic be an instance of something and that something is
an instance of something else?

--

Associations

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

--

Is this equivalent?

sender.id = 'motherboard'
sender    = motherboard

If so, why two notations?

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?

If it is not desirable to force that two association expressions
will share the same association object, we should re-write the
above as:

Hmmm...

Association Object Operator - %

A special operator only to be used for a particular purpose... not
extremely orthogonal feature. And it returns numbers.

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?

This does not look right to me.

The only operator that can be used over the association object is .id.

Why not other things like

%thermal-exchange -> ventilator

?

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? 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? SELECT statement What does it mean to have two SELECT statements: use topicmap1; SELECT ....; SELECT ....; SELECT clause Why should it not be possible to use the -> operator in the SELECT/return clause: SELECT$assoc -> location, $assoc -> event FROM ... Also "Currently it is possible to retrieve the data only as strings." I think returning items is a justified user request. And: Above you generate with %some_assoc a unique ID is this also a string? 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. 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.

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

?

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"

--

Can the comparison operator also work on [topic items] and [assoc
items]?

--

Can I have nested queries?

===

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. === 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. OTOH the TMDM allows it to be NULL (yuck, argh). Same with type (yuck^2). === 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" ? === Is there also the inverse operator type(-1) ? === 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? How can I select all occurrences with a non-empty type (or scope)? Do you use ... and not exists$type

? That would be weird. Or

\$type != NULL

?

===