Re: TOMA: comparison with TMQL

This is a multi-part message in MIME format.
--------------000600070802060507030904
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: quoted-printable

Dear all,

First of all, I appreciate the work Prof. Barta is doing - it is clear=20
he tries to go very far harvesting for ideas for TMQL by examining other=20
work.

In this email I would like to help in that by clarifying some issues and=20
also stating my own opinions on some points.

Before I start, some comments:

1. The document "Toma Spec", to which Prof. Barta refers, is obsolete=20
and instead there are two resources about Toma available:
   - The Toma user manual: http://topiwriter.com/toma/TW_UM_TOMA_100.pdf
   - The paper about Toma from the proceedings of TMRA'06.
However, in order to be able to refer to some of the comments of Prof.=20
Barta, the obsolete "Toma Spec" is still available online:=20
http://topiwriter.com/toma/Toma.html
Note that this last document is obsolete not due to changes in Toma but=20
due to changes and many fixes in the document itself (that became the=20
Toma user manual).

2. In the past, in the one session of the TMQL committee I took part,=20
and in some email exchange before and after, I realized that it is=20
almost impossible to assess new languages other people put forward. In=20
order to assess a language, one should understand it, and this usually=20
implies not only reading the language spec/description. For most=20
suggested languages, there are not yet tutorials, exercises, and the=20
sort, so it is not at all simple to understand the language.
Therefore, I find it a good idea to cooperate with the language authors=20
  not only in getting the different documentation, but also in answering=20
the different tough questions about the language.

Below I comment over different excerpts from the email of Prof. Barta:

> In this sense a
>=20
> provides (provider: laptop,=20
>           provided: adapter,
>           receiver: electricity220) -->> tm://laptops/
>=20
> is easier on the eyes then the TOMA equivalent
>=20
>   insert 'adapter'
>      into (provides)->provider, 'laptop'
>      into (provides)->receiver, 'electricity220'
>      into (provides)->provided
>=20
> And we can re(use) CTM syntax.

However, the above Toma INSERT could (and probably should) be indented=20
differently to be shown as:

  insert 'adapter'        into (provides)->provider,
         'laptop'         into (provides)->receiver,
         'electricity220' into (provides)->provided;

Which is much more readable.

> -- long chains
>=20
> In the TOMA Spec 2.5.2 there is a longish example how to chain several =
path
> expressions while 'climbing' over associations.
>=20
> select $topic
>    where $a(connect_to)->connected =3D 'little_finger'
>    and $a(connect_to)->connected =3D $p1
>    and $p1 not in ('little_finger')
>    and $b(connect_to)->connected =3D $p2
>    and $b(connect_to)->connected =3D $p1
>    and $p2.bn !=3D $p1.bn
>    and $c(connect_to)->connected =3D $p
>    and $c(connect_to)->connected =3D $p2
>    and $p.bn !=3D $p2.bn
>    and $a !=3D $b
>    and $b !=3D $c;
>=20

:-) This example has been provided in order to explain why the following=20
syntax has been developed:

		.role1<-association_id(association_type)->role2

So the above example can be written in Toma as:

   select $topic
     where id(=92little_finger=92).$$<-(connect_to)->$$
                              .$$<-(connect_to)->$$
                              .$$<-(connect_to)->$$ =3D $topic;

or

   select $topic
     where id(=92little_finger=92)
       .connected<-(connect_to)->connected
       .connected<-(connect_to)->connected
       .connected<-(connect_to)->connected =3D $topic;

Which is at least as elegant as:
> In TMQL I would do
>=20
> where
>   $f =3D little_finger
> & $f   <- connected [ ^ connect_to ] -> connected =3D=3D $f'
> & $f'  <- connected [ ^ connect_to ] -> connected =3D=3D $f''
> & $f'' <- connected [ ^ connect_to ] -> connected =3D=3D $f'''
>=20


> --
>=20
> What I found slightly difficult to grasp is that filtering is done quit=
e
> differently, depending on what to filter. To get one particular name fr=
om the
> list, one would do this via

The different syntax points to different kind of filtering.

>=20
>   $topic.bn['central processing unit']
Here we are looking for a basename with the value 'centeral processing=20
unit'.

>=20
>   $topic.bn (abbreviation)
Here we are looking for a basename which is of type abbreviation.
>=20
> Filtering of roles according to the type is using [] again:
>=20
>    ...-> [role-type]

Actually:

      ...->role-type

(so without the square brackets) Here we are looking for a player=20
playing a role of that type.


>   ....$$<- (assoc-type) ->
Here we are looking for a player playing an association of type assoc-typ=
e.


>    $topic.bn @ english
Here we are looking for a basename with scope english.


>=20
> In TMQL filtering is always done with []. Fullstop.

So how do you tell the engine that you want a topic of type t1 and scope=20
s1 and later for a topic of type s1 and scope t1?


> --
>=20
> In TOMA, binding of variables happens in several places. I would be hap=
py to see
> it in the WHERE clause only, but TOMA seems to allow it also in the SEL=
ECT
> clause:
>=20
>   select $topic.bn [ $bn ]
>   where
>          $topic.id =3D 'foo' and $bn ~ '^a';
>=20
> It is not effectively possible to look at the WHERE clause only and the=
n
> evaluate the SELECT expression(s). I could not figure out whether in SE=
LECT
> clauses path expressions in their full beauty can be used. But if so, h=
ow is
> SELECT then different from WHERE?
>=20
> It would be interesting to see a formal definition.
>=20
> All of this is not necessary in TMQL:
>=20
> TOMA:
>=20
>    select $topic.bn @ $scope, $scope.id
>    where  $topic.bn =3D 'lung'
>=20
> TMQL:
>    select $topic / name ( . , . @ )
>    where  $topic / name =3D=3D "lung"
>=20
> or
>=20
>    "lung" \ name / name ( . , . @ )
>=20
Could you give an example of the following in TMQL:

      select $topic.bn@$scope, $scope.bn@$scope2, $scope2.id
       where $topic.bn =3D 'lung';


> -- ad Identification
>=20
> In TOMA, topic identifiers (local identifiers) can be written as either
>=20
>    'foo'
>=20
> or
>=20
>    id ('foo')
>=20
> or
>=20
>    foo
>=20
Not exactly. It depends on the syntax. 'foo' is a string. If it is used=20
in the topic literal id(), it is taken as the id of a topic.
"Naked literal" - foo - can be used inside typing brackets, following=20
the scope operator @ and as the roles in the association expression.

> Identification of topics can also be via their name, but then the path
> expression has to be read from right to left
>=20
>   $topic.bn('Processor')

This is not valid Toma. bn('Processor') is a literal. It can start path=20
expression: it has output which is the topic which has basename=20
'Processor'. But it takes no input. So it cannot be chained after anythin=
g.

On the other hand, .bn is a path expression and can be followed by a=20
typing brackets which contain naked literal:

     $topic.bn(abbreviation)

can be written in Toma and means the basename of type abbreviation.

>=20
> Identification of topics via subject indicators seems to exist, but
> what about locators? What exactly is
>=20
>   $topic.si ('http://....')

This is not valid Toma.
si('http://...') is a subjectIdentity literal. It can start a path=20
expression chaining: it has output which is the topic which has the=20
subjectIdentity 'http://.../'. But it takes no input. So it cannot be=20
chained after $topic.
Note that you have the path expression .si which takes as input a topic=20
and output its subjectIdentity.

>=20
> -- Conciseness
>=20
> Some queries seem to go overboard with the syntax:
>=20
>   select $topic.oc(mass).sc['textual']
>    where $topic.type.super(*) =3D 'device';
>=20
> In TMQL this would be
>=20
>   // device / mass [ @ textual ]
>=20
> or
>=20
>   select $device / mass [ @ textual ]
>    where $device isa device
>


I am not sure how types and classes are dealt with in TMQL. In Toma, I=20
chose not to mix them as it was not mixed by XTM: classes are defined by=20
associations, and types in the topic itself.

The select you quote above, tries to take any descendant of the topic=20
device, that it: any instance of device, any instance of a subclass of=20
device, any instance of a subclass of a subclass of device etc.
In Toma you could also ask to see any subclass of a topic from any level=20
  or any range of levels and the same with types (although usually it is=20
recommended to have only one level of typing, that is: an instance=20
should not have instances).

> -- Unexpected Things
>=20
> What I found unexpected, is that in TOMA, to find all associations of t=
ype
> 'part-whole', one has to write (Example 1 in 2.5.1 of 'TOMA Spec'):
>=20
>   select $a
>    where $a.id =3D 'part-whole';

:-) This is an example of how NOT to find associations of type=20
'part-whole'. The text that follows this example explains it:

In this example the engine doesn't know that the variable $a is an=20
association. It deals with it, as if it were an ordinary topic variable=20
and then looks among all topics which one has the id 'part-whole'.

In order to find all associations of type part-whole you should write in=20
Toma:
    select distinct $a where exists $a(part-whole)->$$;

> --
>=20
> To avoid convoluted path expression chains, a special semantics has bee=
n in
> TOMA, so that two consecutive associations are always different (2.5.2)=
.
>=20
> That seemed quite adhoc to me.

The reason for this is demonstrated in the following:

   select $topic
     where id(=92little_finger=92).$$<-(connect_to)->$$
                              .$$<-(connect_to)->$$ =3D $topic;

We do not want to get as a result for $topic the topic 'little_finger',=20
but without this rule, we would get it (because 'little_finger' is=20
connected to whatever which is connected back to 'little_finger').

I wonder how TMQL solves this.


> -- XML and TM content
>=20
> TOMA obviously cannot generate TM or XML content. Now Rani will claim t=
hat this
> is a template thing. But it is not, I think, and even if it were, for
> performance reasons this should be part of the language.

Rani indeed claims that this is a template thing :-)
I have put as a focus to have Toma as simple and as small as possible.=20
It is TMQL, TMCL and TMML and nothing else.
I assumed that users that want to create applications using Toma or any=20
other TMQL will use in addition other technologies (Java, Perl, Python=20
etc.). Each of those technologies provide sets of techniques and=20
methodologies to create XML content as well as any other content. Why to=20
extend the language to include another such technique?
And what are the performance reasons here?
>=20
> -- Output handling
>=20
> The query result is always the 'textual representation' of the output, =
right?
>=20
> What if this is a list? So it is a list of textual representations, not=
 their
> concatenation, right? How to control that you do _NOT_ want the string,=
 but the
> characteristic itself?
>=20
> In TMQL, the default is 'atomification', i.e. the conversion of charact=
eristics
> into the value they contain. In this process, the scope and the type ar=
e
> lost. This, so I assume, is what most users are asking for.
>=20
> TMQL:
>=20
>   robert / name    # auto-atomification at the end, one gets a string
>=20
>   robert / name [ @ nick ] # ditto, but after filtering for this scope
>=20
>   robert >> characteristics name # get the whole characteristics item
>=20
Toma returns indeed always textual representation of the output.=20
However, it is very simple to instead return the objects themselves.=20
This syntax was even available in earlier versions of Toma and was not=20
forgotten:

    SELECT ... AS XTM WHERE ...
or
    SELECT ... AS OBJECT WHERE ...

It is even not too difficult to implement it, the moment we understand=20
how we provide an object. For example, TopiEngine support an=20
implementation of TMAPI like API in C++ where C++ objects are available=20
for the different Topic Maps objects.

The reason I didn't include this in Toma was that I didn't have a real=20
use case for it. After all, when I get a topic ID, I can use the TMAPI=20
to get the topic in a very similar fashion.

> -- Functions and Data Types
>=20
> TOMA's choice here is ad-hoc, in TMQL we have to think more lateral.
Can you explain this please?

>=20
> -- Ordering
>=20
> In TOMA one has to refer to a 'column number', so this is a bit brittle=
, when
> you fiddle around with the SELECT clause. Or maybe the example there is=
 just
> misleading.
>=20
> In TMQL ordering can be done via a stand-alone path expression, i.e. on=
e can
> order according to something which is NOT even in the SELECT clause
>=20
> select $p / name
>   where $p isa person
>   order by $p / age desc

This is a design decision I have made in order to make things a bit=20
simpler for the user (I hope). When you sort by anything that is not in=20
the SELECT clause, you might get into confusing situations.
For example, when trying to sort the names of topics by the topic types:=20
there are more names then types, so how to sort the names exactly?
And if you sort by basenames and not all topics have basenames? how to=20
sort the topic ids?

When thinking about it I have realized that from the implementation=20
point of view the two choices are very similar. If you wish - sorting by=20
something that is not in the SELECT clause meaning to add a hidden=20
column to the SELECT clause and sort by that hidden column.
So instead of doing that, I decided that the user will add this column=20
explicitly instead of the engine doing it implicitly.
This way the confusion is avoided: when you sort by a column you see,=20
you probably understand better how things are sorted.

>=20
> -- Implicit subclassing
>=20
> In TMQL the default is that subclass hierarchies are honored. So when y=
ou do a
>=20
>    $person / size
>=20
> then you get all occurrences of this type and all its subtypes, so also
> shoesize, hatsize, whatever is available in the map and it is made expl=
icit that
> shoesize iko size and hatsize iko size, etc.
>=20
> TOMA seems to have a 'strict' interpretation. The problem with that is =
that it
> can be cumbersome to write queries which are robust against subtle chan=
ges in
> the type structure. So the 'immediate type' or 'immediate subclass' may=
 change;
> if we allow programmers to rely too much on it, our applications are al=
l dancing
> on thin ice.
Indeed in Toma one should write the following:

	$person.oc($type) and $type.type.super(*) =3D 'size'

to get the same effect.

I didn't realize the importance of such queries. I wonder if you would=20
recommend to change the way Toma interpret such types - so types of=20
basenames, occurrences, associations and roles to include by default any=20
instance of any subclass of the written type (as size is interpreted in=20
$person / size).

>=20
> \rho
> _______________________________________________
> tmql-wg mailing list
> [email protected]
> http://www.isotopicmaps.org/mailman/listinfo/tmql-wg
>=20

Kind regards,

Rani

--------------000600070802060507030904
Content-Type: text/x-vcard; charset=utf-8;
 name="rp.vcf"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="rp.vcf"

begin:vcard
fn:Rani Pinchuk
n:Pinchuk;Rani
org:Space Applications Services
adr:;;Leuvensesteenweg 325;Zaventem;;B-1932;Belgium
email;internet:[email protected]
title:Software Engineer
tel;work:+32 2 710 15 85
tel;fax:+32 2 721 54 44
x-mozilla-html:FALSE
url:http://spaceapplications.com
version:2.1
end:vcard


--------------000600070802060507030904
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
tmql-wg mailing list
[email protected]
http://www.isotopicmaps.org/mailman/listinfo/tmql-wg

--------------000600070802060507030904--