[tmql-wg] Re: [tmcl-wg] TMPath - experiments summary

[Robert Barta]

On Mon, Jul 21, 2003 at 12:58:28AM -0400, Dmitry wrote:
> I tried to summarize results of my experiments with XPath-like language for
> Topic Maps.
> That's what I have so far...TMPath Introduction
> http://homepage.mac.com/dmitryv/TopicMaps/TMPath/TMPathIntroduction.html

Dmitry,

Sorry that it took so long to respond to that, but I have been under some load
recently. I analysed this with great interest, especially since there are some
similarities with what I tried with AsTMaPath

  http://astma.it.bond.edu.au/astma%3F-spec.dbk?section=10

Like in your proposal I distinguish between lateral movements (topic ->
association(s) -> topic(s) -> association(s) ....)  and drill-down movements.

While I will send a more detailed mail privately, here some general
observations:

	- I think languages like these will not only be necessary for
	TMQL/TMCL but also for the TM update language (TMUL? :-).

	- The fact that you have a loop, if and quantifiers in the
	language makes it a complete query language if we ignore the
	content generation part (and some bells and whistles
	necessary).

In fact, TMPath should be translatable into AsTMa?, or vice versa. For example,

   for $x, $y in
       every $x in /person
          satisfies some $y in /person
             satisfies $x/hasManager()[who = ..]/role::manager == $y
   return
       .....

can be transformed into (if I understand it correctly) into AsTMa?
using AsTMa! patterns:

   # using patterns
   forall [ $x (person) ]
      => exists [ $y (person) ]
         and
         exists [ (hasManager)
                  who     : $x
                  manager : $y ] # in whatever-map...
   return
       .....

To make the similarity between the languages more obvious, we
ad-hocish allow test (predicates) in AsTMaPath:

   # using path expressions only
   #            this     role      assoc-type   role
   #              |       |            |          |
   #              v       v            v          v
   forall $x in *[. -> subclass \ subclasses / class = 'person']
      return forall $y in *[. -> subclass \ subclasses / class = 'person']
                           [. -> who \ hasManager / manager    = $x      ]
        return
           .....

Lars is usually concerned that predicates together with navigation
overlap with the pattern matching approach making the language
non-orthogonal. Using Perl a lot has taught me that exactly this
overlap can make a language VERY handy, so I am not so overly worried
as long as this can be orthogonalized underneath (for describing the
semantics). Developer convenience is a higher good for me.

What I probably want to say is that theoretically - as you have done
it - it should be possible to do _everything_ with path expressions. I
find pattern a bit more readable, though, because I can bind several
variables at once.

\rho