[tmql-wg] Re: [tmcl-wg] TMPath - experiments summary
Thu, 31 Jul 2003 14:01:43 +1000
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
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
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
- 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
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
can be transformed into (if I understand it correctly) into AsTMa?
using AsTMa! patterns:
# using patterns
forall [ $x (person) ]
=> exists [ $y (person) ]
exists [ (hasManager)
who : $x
manager : $y ] # in whatever-map...
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 ]
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.