[tmql-wg] tolog 0.1 draft specification

[Lars Marius Garshol]

* Robert Barta
| 
| 2.1 Operator clause: In [7] there is no explicit '='. If this is
|     intended, one is supposed to express equality by unification?

Correct. In later versions which support literals in queries we'll
have to introduce '=', but it wasn't needed in 0.1.
 
| 2.1 Or clauses: Syntax cant be right. '}' is probably wrong.

What's the problem?
 
| 2.1 You have the 'not' in front of a clause list. If I want a clause
|     to be negated I have to write
| 
|       not ( my-clause-here )
| 
|     and not
| 
|       not my-clause-here
| 
|     ? 

Note the use of quoted symbols in the BNF. The parentheses are quoted,
and that means they are terminals, so your first alternative is
correct.

| And all the clauses in the ()'s are ANDed before the not?

Not necessarily (*groan*), they are just evaluated, and then applied
to the query. The rest of the spec will spell this out, though.
 
| 2.1 In [18] I miss a []+ somewhere. And can't strings contain
| escaped \"'s?

You are right on both counts. I've now added a note to say that
support for escaping has to be worked in.
 
| 2.2 Comment: the keyword 'FROM' seems to have a rather different
|     meaning than the 'FROM' in SQL. In SQL I refer to a set of tables;
|     in tolog it is predicates in clauses.

Correct. In tolog 'FROM' is really just a separator between the
variable list in the 'SELECT' and the query proper.
 
|     In the query I wonder how to address a particular map.

The query doesn't allow you to specify which map(s) is/are being
queried. That's done outside the query.
 
| 3 : "Query results consist of a list of sets of (variable, value) bindings."
| 
|     So : one variable binding is a tuple (var, val)
|          one match consists of several such tuples
|          one result is a list of matches
| 
|     Right?

Yes. Should I explain that more clearly, you think?
 
| 4.2. direct-instance-of
| 
|     Working with AsTMa! I started to wonder whether there is such
|     thing as a "direct instance of". Yes, someone can author it, but
|     who knows what happens over the course of time: New intermediate
|     topics might be introduced.
| 
|     What I am saying is that this concept is not robust. In AsTMa!?
|     I have not allowed to base queries on it.

I'm not sure what your concern is. We've seen again and again that
there are cases where you want to query the type-instance associations
to see which associations are in there, regardless of the semantics of
that specific association.

One case where I use this is a module in the autogen toolkit which
does the following query:

        processor.load("""descendant-of($B, $C) :- {
          super-sub($B : sub, $C : super) |
          super-sub($B : sub, $D : super), descendant-of($D, $C)
        }.""")
        results = processor.execute("""
          select $A, $C from
            direct-instance-of($A, $B),
            direct-instance-of($A, $C),
            $B /= $C,
            descendant-of($B, $C)?""")

It then removes the redundant C types for all the As. There are many
other use cases for this as well.
 
| 4.2 "...represented directly..."
| 
|     What do you mean here?

Indeed. I should cut that. Now done.

-- 
Lars Marius Garshol, Ontopian         <URL: http://www.ontopia.net >
GSM: +47 98 21 55 50                  <URL: http://www.garshol.priv.no >