[sc34wg3] And yet another...

[Robert Barta]

On Fri, Jul 23, 2004 at 09:48:13AM +0200, Lars Marius Garshol wrote:
> 
> I've written up and published my proposal for a foundational model for
> topic maps.

Lars,

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?

- 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.

- 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.

  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?

  [ 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. ]

  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.

----

  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.

  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.
  
  In fact, Prolog programmers play around with all sorts of tricks (cut,
  reordering, ...)  to make the programs (a) either terminate or (b) faster.

  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.

--

  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....

\rho