[sc34wg3] Re: FYI: Yet another TMRM Formalization (well, not really)

[Jan Algermissen]

Robert Barta wrote:
> 
> On Wed, Jul 14, 2004 at 07:24:08PM +1000, Robert Barta wrote:
> > Hi all,
> >
> > FYI, this is our current working paper here to capture "the essence of
> > TMs".

Robert,

some comments/questions based on a short read:

1.1:
- Do you mean that Tau has two elements, the set of names and the set of literals
  or that Tau is the union of them?

- Are the predefined identifiers (id, instance, class, superclass subclass)
  names or literals or a third kind?

- In assume that all names come from a single namespace, right? What about the
  literals? If you use literals for the purpose of identity, all literals
  must also come from a single namespace, or they must carry around with them
  an implicit namespace. OTH, you say they don't, they are just numbers or
  quoted strings. So, how does "grroop" provide identity?

- You say N is a collection, so can the same name be contained in N twice?
  What are the implications for Tau?

- This is pretty close to RDF (single namespace for names (URIs) plus literals)
  OTH, RDF combines literals with domains to enable them to provide idetity.

- Why are the names in a special collection they are also just literals, or?

1.3:

- You write that "we do not want to build in any particular merging rules into
  our model at this stage,..."
  You are proposing an assertion model that allows a single role to be played
  more than once (which is the only difference from the TMRM assertion model)
  and while this seems fine now[1] I promise you that the problems will
  immediately arise when you try to *implement* merging (which requires to
  detect assertion equality, which is hard to do efficiently in the case of
  multiple role players[2]). 
  I suggest to never set merging aside 'for the beginning'. I did this 3 or 4
  times only to find out my mistakes when I started to implement merging
  in the end!


In general:

- I think the issues around merging and values (literals), and how to
  query for certain values are much more important than the assertion
  structure. How do you implement: "give me all literals which are
  numeric and > 4487" without a complete scan of all literals?

  If literals are not typed, access paths (indexes) cannot be implemented
  (besides hasing).

  I really urge us not to ignore all the research that has been done in
  the RDBMS world for decades.


- Interestingly, what you describe is an *Application* of the RM. You
  define (although implicitly) a set of properties and a certain
  assertion structure (also only a set of properties as in the
  assertion structire propsed by the RM). In essence, you defnine
  a TMA (and operations on the properties provided by this TMA).

  While you say "with a faint similarity with TMRM", let me
  clarify that the purpose of the RM is to provide a means to
  express TMAs (such as yours, or the TMDM) and to enable
  interoperability between them. In fact, the RM enables you
  to write a mapping TMA between yours and the TMDM.

  Rather simplified you can also put it that way: The RM enables
  the definition of TM schemas and your paper defines such a
  schema, just not in RM language (in essence: TMA == Schema).


I hope this clarifies matters a bit. If my language sounds too
offensive, please take my apologies, I do not mean to sound rude.
I maybe just got carried away by the issues.

Jan



[1] I find multiple role players very questionable, because IMHO the
    itentity of a role is based on the context that the other roles
    provide[3]. If a role may be played multiple times, what is its
    meaning? Is the number of times actually limited (as in the
    case of relationships such as 'opposite') and how do you express
    that....
    See also [4] on this.

[2] If roles are only played once, you can directly compare ordered
    assertions to check equality, for example. 

[3] http://www.infoloom.com/pipermail/topicmapmail/2002q1/003566.html

[4] http://www.isotopicmaps.org/pipermail/sc34wg3/2003-April/001767.html
      

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