[tmql-wg] Toma - Use Cases Solution

[Robert Barta]

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
came across reading your spec/examples.

\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

?


===