[sc34wg3] Comments on Tau model

[Jan Algermissen]

Lars Marius Garshol wrote:
> 
> --- HIGH-LEVEL COMMENTS
> 
> I guess my key question for the author of this model is why he chose
> the particular structure he did. As far as I can tell, almost any
> underlying structure would have served the purpose, since it is the
> operations that do the job. To put it another way, couldn't the exact
> same set of operations have been used on a quad model? Or on some
> third model?

Lars,

that is exactly the point I am trying to make. Without some requirements,
the choice of the underlying model is arbitrary.

...

The primary thing to consider (IMHO) is the tradeoff between the structural
freedom an abstract information structure provides and general implementation
efficiency. For example, the entity relationship model forces you to classify
your entities (and only once!) but this structural limitation makes it possible
to store certain sets (the table columns) of attributes in a single record,
allowing access to them in a single (IO-)operation.

Robert's proposed information structure is extremely unconstraining, which
provides great freedom for the data modeler but does not provide the implementor
with much structure that can be relied on for efficiency. Even the whole idea
of merging would have to be handled by the query language (by the operators
in general).

RDF for example has a similar flexibility but OTH does not allow at the
model level, to express that a single resource (in the HTTP sense) has
more than one URI. That means, an RDF store cannot provide implementation
of this idea and handling these situations is left to the user in terms
of e.g. the owl:same predicate.

Of course, a store can implement the owl:same semantics, but then it
uses more information than has been provided by the data model itself. It
would be like an RDBMS that comes with a set of predefined tables for some
specialized task.


These are the issues that (IMHO) need to be considered and the choice of
the abstract information structure is by no means a matter of taste, but
a matter of choosing a wise tradeoff between modeling flexibility and
implementation efficiency possibilities.

Jan


> 
> The structure of Tau assertions is, it seems, different from both the
> structure of TMRM assertions and TMDM associations. As far as I can
> tell, there is no groupings of players of the same role (role type in
> TMDM), nor does there appear to be any support for assertion types. Or
> is that supposed to be indicated with some undefined role type?
> 
> --- DETAIL
> 
>   "Literals may be numbers of quoted strings"
> 
> Why just two types? In fact, why are the types specified at all? As
> far as I can see they aren't used anywhere.
> 
> What is the predefined identifier "id" used for?
> 
>   "The sets of assertions is denoted by /A/."
> 
> This should be "set of all", right?
> 
>   "Assertions are by default anonymous, but we can name them a
>   predefined role id."
> 
> What does this mean?
> 
>   "That way assertions are only equal if they have identical members."
> 
> Surely that applies anyway?
> 
> In 1.3 there are actually two merging rules. If a map is a set of
> assertions there is an implicit merging of equal assertions. The same
> happens when maps are composed using set union.
> 
> 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.
> 
> Regarding 2, are you sure that instances/subclassing belongs in the
> core model? In my view this is more suitable for user-space
> vocabulary.
> 
> /A^n/ is presumably the same as /A x A^n-1/ (ie, /A/s cartesian
> product with itself n times)?
> 
> 2.2 uses the terms "concept" and "object", but as far as I can tell
> this is the first occurrence of these two terms.
> 
> In 2.2 there are no assertion types. Traversal of the assertions is
> done purely in terms of role types, and no assertion type is tested
> for.
> 
> Also, the operations in 2.2 would produce results for assertions of
> the form (using LTM syntax for simplicity):
> 
>   whatever(a : superclass, b : subclass, c : superclass, d : subclass)
> 
> Surely there is a missing set of constraints here?
> 
> In "is-a<sub>m</sub><sup>0</sup>", what is the 0 doing there? Is it
> because you're following 0 subclass steps? Isn't it better just to
> lose that 0?
> 
> 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.
> 
> --
> Lars Marius Garshol, Ontopian         <URL: http://www.ontopia.net >
> GSM: +47 98 21 55 50                  <URL: http://www.garshol.priv.no >
> 
> _______________________________________________
> sc34wg3 mailing list
> sc34wg3@isotopicmaps.org
> http://www.isotopicmaps.org/mailman/listinfo/sc34wg3

-- 
Jan Algermissen                           http://www.topicmapping.com
Consultant & Programmer	                  http://www.gooseworks.org