[sc34wg3] And yet another...

[Lars Marius Garshol]

* Robert Barta
|
| Part III
| 
| - You again use the predicate 'direct-instance-of'. Again, I raise
|   the issue whether this is a good practice to offer these
|   things. In practice new subclasses may be introduced and removed
|   during the course of time. Should, because of this, the outcome of a
|   queries change?
|
|   Should not programmers be encouraged to write robust queries which
|   survive these fluctuations?

That's a separate discussion. I just took tolog as my example TMQL to
show how the quad model could be used with it. Whether or not tolog is
good is a completely different discussion.
 
| - You have not covered all cases of FORALL p EXISTS q and SOME p
|   SATISFY q.  Since you map this into Prolog/Datalog this should not
|   be a problem. Still, I would like to see whether you can transfer
|   the semantics.

So would I, but there wasn't time. This is one of the open issues.
 
| - You write that
| 
|      If we take tolog as the model then a magic predicate (not visible
|      in the language) called '_quadruple' can be defined, and all
|      other built-in predicates (except /=) defined using this. To wit:
| 
| 	type($X, $TOPIC) :- _quadruple($X, TYPE, $Q, $TOPIC).
| 	topic-name($TOPIC, $NAME) :- _quadruple($TOPIC, TOPIC_NAME, $NAME, $V).    
| 	variant($TNAME, $VARIANT) :- _quadruple($TNAME, VARIANT, $VARIANT, $V).
|         ....
| 
|   What you are saying is that tolog can be easily reduced (read
|   implemented) using a single predicate. I certainly buy that.

Yep.

|   In fact, this leads to the question why tolog is not simply a set
|   of a few rules like these above? Why fuss around with a query
|   language at all? Why not use Prolog and add 10-15 rules (like the
|   ones above) and we are done? Why go through the whole circus of
|   specifying a query language?

There are several reasons for this:

  - Prolog is unsuitable for a query language because it is
    Turing-complete

  - a custom syntax provides us with far better support for topic maps
    (crucially through dynamic association predicates, which account
    for most of what is done with tolog)
 
|   [ In fact, you yourself said many times that tolog is not specific
|     to topic maps as it can query "anything you like" (RDF, relational
|     stuff). It is just using the logic programming paradigm behind
|     tolog. ]

Yes.
 
|   And if we do this with TMQL what should stop us to express
|   constraints as Prolog rules? Maybe tweak a bit with the syntax
|   (use SELECT, WHERE and ? to give SQL developers a warm feeling
|   :-), but use Prolog.

I don't think that would give us a very good query language, for the
reasons given above.

Also, as was agreed in Amsterdam, we want the path expressions, which
certainly do not exist in any way, shape, or form in Prolog.
 
|   My answer, why a dedicated QL and CL for TMs would make sense in
|   the first place, is that we DO NOT WANT a predicate approach.

Uh?
 
|   Why? I think, because of computational complexity (read: potential
|   speed). A predicate approach like in tolog is coming with
|   Datalog. Datalog (please correct me) is based on Horn-Clauses.
|   Horn clauses are restricted FOL expressions. Unfortunately,
|   problems expressed with Horn clauses are not fully decidable,
|   i.e. for a given set of data and a given set of horn clauses, the
|   resolution algorithm may find a solution. Or not. Or it just may
|   take long.

Datalog is based on Horn clauses, yes, but it's fully decidable. And
since we would here be creating the evaluation algorithm ourselves it
would be up to us to ensure that it was decidable. I don't see that
this is an issue in any way.
   
|   In fact, Prolog programmers play around with all sorts of tricks
|   (cut, reordering, ...)  to make the programs (a) either terminate
|   or (b) faster.

Prolog is *very* different from Datalog. Their evaluation algorithms
are completely different. Prolog is Turing-complete, but Datalog has
the same expressivity as SQL3. I think discussing Prolog in this
context just confuses the issues, really.
 
|   This could imply (I am not a logician but I am not the one
|   proposing the TMQL semantics based on Horn clauses), that some
|   things may not be 'provable', like the subsumption "Is a mother a
|   woman", something you immediately need when you process queries
|   together with ontological knowledge.
| 
|   This is EXACTLY the reason why OWL DOES NOT USE FOL (first order
|   logic) but varies flavours of DLs. For most of the DL flavours
|   VERY efficient algorithms are known by now. And these are
|   guaranteed to terminate. Something which may be mostly relevant
|   for the kinds of applications in the semantic web arena.

I think you are reading more into my notation than what is there. If
you go back and look at the actual document it describes a few
operations (predicate application, predicate application chaining,
union, set difference, and probably a couple of others). *That*
language is what we are discussing, not FOL, though admittedly what I
wrote may have made it lookas though that's what I meant.

I guess you could argue that it seems silly for us to define our own
language when these other ones exist, but I think you've already
argued quite convincingly why we can't use the existing ones. And you
are yourself defining a semantics from scratch so the only real
difference here is that what I'm doing looks similar to something that
already exists (and probably this confused you) whereas you're doing
something that's much harder to confuse with something else.

|   So, if we do not want to disqualify ourselves out of this market
|   at this stage, a query/constraint language should not be like the
|   tank in a glass shop.  Yes, you have the power to fire granades,
|   but....

Agreed.

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