[sc34wg3] N0391-0394: New SAM/XTM documents

[Jan Algermissen]

Robert Barta wrote:
> 
> On Mon, Apr 21, 2003 at 09:47:28AM +0200, Jan Algermissen wrote:
> > >    Given a TM and a constraint C: What is the result of applying the constraint?
> >
> > What exactly do you mean by constraint?
> 
> Something which looks like the constraints in the TMCL requirements
> document on www.isotopicmaps.org/tmcl/
> 
> > >    Given a TM and a query Q: What is the result of the application?
> >
> > I have developed a query language that is expressed solely in terms of the
> > TMM (meaning that it works for any TMA) and I'll try to think what I can
> > do with it regarding your sentence above.
> 
> Interesting, can we have a look at it?

Well, not yet (if only all days had at least 48 hours....) but an
early version (based on an early version of the RM) is living at:

http://www.gooseworks.org/stmql.html

It would have to be a bit more generic (in terms of identifying
subjects) but the idea is the same. Also, the part that will
enable traversals (start at topic X, go to all it's role playings
of role Y and then go to the association and return it etc..)
is missing completely.


> 
> > >    Given a TM and an update U: What is the result?
> >
> > An update in topic maps land is a merge, right?
> 
> Or a negative merge, depends how you do it, yes.
> 
> > > But this is - obviously - connected with what languages we will use
> > > for this.
> >
> > So, I'd have to write a constraint language for TMM, yes?
> 
> If you have a query language, then from that you should be able to
> factor a constraint language.
> 
> > > And this is exactly my point: I cannot see how TMM/SAM can
> > > host infrastructure for something where we have not decided what it
> > > should do.
> >
> > I don't understand you here, can you explain?
> 
> As I understand the formal process the requirements docs for TMCL and
> TMQL are not yet agreed upon. So, formally speaking, it would be
> difficult to fully spec a """"model"""" which can already host these
> languages.
> 
> > > I might be wrong here, but my gutt feeling tells me that including
> > > this into the discussion now would be to put the cart before the
> > > horse. I would feel much better if we would concentrate on the (a)
> > > 'simple processing conformance' now and do a revisiting how SAM/TMM
> > > correlate with the query processing model (b) later.
> >
> > I think we first have to define what topic maps essentially are (what
> > are the essentials of the topic map data model) so I assume I think
> > just the opposite of what you think.
> 
> I agree, that we disagree :-) For me it is important that I can use TMs
> for all ontological activities:
> 
>    - authoring & maintaining
>    - filter according to constraints
>    - validate against contraints
>    - query
>    - distributed storage
>    - large scale deployment
> 
> I see this so more from an engineering view point and less from an
> "what is the essence of a TM" one. 
> This is my lesson which I got from
> category theory: there are no ULTIMATE packages/classes. It all depends
> on what you do.
> 
> > > In many cases applications will only need (a) for the time being,
> > > anyway, I would guess. And: The simpler (a) is, the better the chances
> > > to harmonize it with (b).
> >
> > What does 'simple' mean in this context? I'd say that we cannot get much simpler
> > than the TMM, or?
> 
> Well, a thing is 'perfect' if you cannot remove anything from it
> without destroying it. The number of constraints in TMM is impressive,
> though. 

I have tried a lot to remove some, but (at least for me) it turned out
that all of them are neccessary. From my experience of implementing TMM,
I even know that there are propably a few more (regarding value types
for example). 

Defining (and constraining) the structure of an assertion (= how does a
real world relationship look in a topic map) really does lead to the
(I think rather obfuscating) section that defines all the properties that
express the assertion structure. In the former draft this section was 
expressed in terms of arc types and 'forms of connectedness' and that was not
easy to parse either. 

Anyway, the assertion structure is essential and the constraints on the properties
are too. Any suggestion how to make the prose simpler is welcome (we could not do
better so far).


> 'Simplicity' is not the first word which would come to my mind
> :-) TMM is almost as long as the core specs of all my AsTMa languages
> (not including the update) together.

But the length of the document and it's simplicity are not neccessarily
proportional...

Thanks Robert, this discussion is very valuable to me. I don't yet
fully understand everything you said, but I'll try.

Jan


> 
> \rho
> _______________________________________________
> 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