[sc34wg3] Comments on Tau model

Lars Marius Garshol sc34wg3@isotopicmaps.org
Tue, 27 Jul 2004 09:24:16 +0200


* Robert Barta
| 
| Yes, it's the operations which count. But: Whenever you choose a
| 'particular structure' then you - in the same step - implicitely
| choose the operations which come with it.

Up to a point, yes.
 
| I would not know why you could not do that. Maybe the description is
| a bit different in complexity.

Yeah, I think the complexity of the resulting description is the test
for all of these models. I think the problem we have right now is that
none of them have been carried forward to the point where we can judge
the complexity. I'm not sure what to do about that.

(Below I cut your answers to a lot of my questions, since there's not
much of interest to say to a "Yes" response. :-)
 
| No, as every assertion is a thing by itself which can be referenced
| in any other assertion the 'type of an assertion a' is expressed by
| another assertion which happens to have the right roles (class,
| instance).

Well, for more on that see my other set of comments.
 
| So there is no special treatment for "association types".

In that case it seems to me that the TMDM representation in the Tau
model is going to be quite large and that potentially it may be
difficult to use it to define TMQL. I may be wrong, but these worries
crop up immediately.
 
* Lars Marius Garshol
|
| In 1.4 the two basic operations are defined. Interestingly, since all
| is defined in terms of roles in assertions, this is very similar to
| the FM I proposed, if the model I used is changed to use the structure
| I used for associations for *all* statements.
 
* Robert Barta
|
| Ye....es. I think it this is a consequence of getting rid of topics,
| moving everything into assertions/quadruples/...  Since you only
| have now assertions, you only have to worry about these.

That's probably correct, but I find it very interesting that the model
you came up with is so close to the one I envisioned. On the subway to
the office this morning I was thinking we should just go with the Tau
model and see where it got us. Now that I've seen your answers I'm not
so sure any more.
 
* Lars Marius Garshol
|
| Regarding 2, are you sure that instances/subclassing belongs in the
| core model? In my view this is more suitable for user-space
| vocabulary.
 
* Robert Barta
|
| No, I am not sure, whether it belongs here.
| 
| But: 1) These both assertions types are so inherent in our
| ontological thinking that they would have a right to be first-class
| citizens.

I don't think that necessarily follows. Note that XTM 1.0, TMDM, and
RDF all chose a different approach.
 
|  [2] 2) As you pointed out already there is a need to express an
|         assertion type and as you point out below the basic operations
|         DO NOT make use of this assertion type.
| 
|         Now, in practical cases I would like to say
| 
|            lars -> player / plays-squash-somewhere
| 
|            ^^^^    ^^^^^^   ^^^^^^^^^^^^^^^^^^^^^^
| 
|            thing   role     association type
| 
|         and not just
| 
|            lars -> player
| 
|         To define such convenient operations I need to have
|         /instance-of/ inside the formalism.

True, but this is what TMDM calls "type" and not "instance of". I
guess we should leave this alone until we've seen how TMDM is
represented in the Tau model.
 
* Lars Marius Garshol
|
| In 2.3 the list of operations provided is, interestingly, very
| nearly the same as the one I sketch in my FM proposal. Yours is of
| course much more detailed, but it's interesting that the operations
| seem to be the same.
 
* Robert Barta
|
| I wonder how the exists and forall things look like in FM. 

I don't know, really. If it turns out that Tau does this much more
neatly then that's a strong argument in Tau's favour, I'd say. I think
we all have more work to do here before we're ready to make a
decision.

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