[tmql-wg] Toma - Use Cases Solution
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
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.
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
return? A list of topic which are the classes?
return the sometopic as well?
If the operator .type(n) is always used in a comparison, then a predicate
is_instance_of (A, B)
is probably better than
A.type = B
Why cannot a topic be an instance of something and that something is
an instance of something else?
How can 'city' be an association? Or even an association type?
Is this equivalent?
sender.id = 'motherboard'
sender = motherboard
If so, why two notations?
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
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
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
All association objects of this type? Or only one which is
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
In the expression
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?
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?
What does it mean to have two SELECT statements:
Why should it not be possible to use the -> operator in the SELECT/return
SELECT $assoc -> location, $assoc -> event FROM ...
"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?
"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.
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.
"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
"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
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
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
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