TopicMaps

Adequateness < SQL as TM Query Language? No, thanks! < < Home

Adequateness

Let us look at some use cases. With all your SQL knowledge, can you guess what this TMRQL query does? (reformatted for better reading):

SELECT name_value 
  FROM tm_assoc
  JOIN tm_nameValue on r1p=topic_id
  WHERE r1t=@author
  ORDER BY dbo.tm_sortName(r1p)

OK, without any knowledge of TMQL (please ignore details in the syntax, this is all in flux), can you guess what this does?

SELECT $a / bn
WHERE
      $a is-a author
ORDER BY $a / bn @ sort

It extracts the basenames of all things which are instances of 'author' and sorts this list according to the name in the scope 'sort'. It also works for things which are indirectly authors, such as 'science-fiction authors' and 'poets' which all subclass the concept 'author'. I doubt the TMRQL version honors this.

Another one: To find all documents in a map, sorted by publication date (ascending), only number 3 to 5, one would write in TMQL something like this:

for $d in %_ // document
order by $d / rd [* publication-date]
return
  (position(), $d / bn`, $d / rd [* publication-date] `) [3..5]

or - if you are one of these beardy Perl-hackers who want to do everything in a single line - you may write:

%_ // document < $#, ./bn`, ./rd [*publication-date]` > order by @_[2] asc [3..5]

The TMRQL solution for this is:

SELECT dbo.tm_displayName(topic_id), occur_value 
FROM tm_occurValue 
WHERE 
   occur_type = @pubdate AND 
   topic_id IN 
        ( SELECT topic_id 
          FROM tm_topic WHERE (type_id=@document)
               OR (type_id IN 
               ( SELECT to_id
                 FROM dbo.tm_tc (@document, @subclasses, @superclass, @subclass) 
               )
         )
    )

I would not bother that it is much longer than the TMQL solution. But there are numerous references to external variables and this query has three (!) levels of selects.

There are also impressive examples like the one which uses an SQL cursor. This is necessary because for the transitive property like 'is-influenced-by' in the relational model a temporary table has to be filled first with all the relevant entries. Only then a SELECT statement can use this knowledge.

In a semantic environment transitivity, reflexitivity and other properties of associations are inherent. What the example shows is that the relational database does not natively understand this. TMQL does:

using adhoc[tolog] for
   is-influenced-transitive ($A : influence, $C : influenced) :-
      is-influenced-by         ($A: influence, $B : influenced),
      is-influenced-transitive ($B: influence, $C : influenced)

SELECT $influenced, "influenced by" , $influence
WHERE
   is-author-of ($influencer: author, $influence: opus),
   adhoc:is-influenced-transitive ($influence: influence, $influenced: influenced)

And a TMQL implementation might even choose to be 'lazy', i.e. return results as they are computed. Having to fill a temporary table for TMRQL first would not allow such a thing.

I think, what this shown is that developers have to think in 'tabular terms' whereas the structure they want to query is a graph-like one.