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

[Robert Barta]

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?

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

\rho