Re: PMTM4 templates vs. TMCL (was: Re: [topicmaps-comment] RE: OASISvs W3C)

[Lars Marius Garshol <larsga@garshol.priv.no>]

To summarize before I begin to address the different issues, we seem
to have identified three issues related to TMCL:

 1. shall TMCL constraints be part of the topic map?

 2. shall TMCL constraints be expressed using the association template
    mechanism of PMTM4?

   a) are PMTM4 association templates powerful enough for what is
      needed?

   b) does this use of PMTM4 association templates introduce dangerous
      structural issues into the topic map architecture?

I start by discussing 1., which SRN seems to have addressed, then move
on to 2.b), which I thought he intended to address.

* Steven R. Newcomb
| 
| PMTM4 merely explains how sets of constraints -- constraints that
| might be expressed in TMCL -- actually participate in the Topic Map
| as topics.

This immediately raises the first question. Should the topic map
schema be part of the topic map, or should it not? This can be argued
both ways, and I think we're not yet ready to draw a conclusion.

| In any case, even leaving PMTM4 aside for the moment, the
| specification of how the role-player constraint topics are connected
| to the associations that they constrain is quite orthogonal to the
| issue of how those constraints are expressed (e.g., in TMCL).

Agreed.
 
| The constraints that will be established by TMCL expressions will
| also be reifiable as topics.  

This will necessarily be true, since they will have addresses.
 
| Neither the Topic Maps paradigm nor PMTM4 constrain how the subjects
| of topics can be expressed ("indicated").  TMCL is going to be a
| perfectly good way of expressing such subjects, and, I hope, better
| than most.

That has to be the goal for all of us.
 
| I would be deeply disappointed in the outcome of the TM
| standardization process if we abandoned one of the cardinal
| requirements that has always driven the design of TMs.  That
| requirement is that any subject that affects the meaning of a topic
| map must be reified as a topic in that same topic map.

I agree that the topic that reifies the class of which other topics
are instances must be part of the topic map. This is not the same as
requiring the constraints on that class to be part of the topic map.

Let's say that there is a constraint which states 'all topics which
are instances of the class "country" must have a base name in the
scope "native-name"'. Does there need to be a topic in the topic map
which represents this constraint? (I'm trying to make sure we are
arguing about the same thing here.) If this is necessary, why is it
necessary?
 
| * recognized player of role classes are topics  <<-- this is the one
|                                                   we're talking about.

This is only true while you are wearing PMTM4 spectacles.
Non-believers don't see it the same way.


 
By the way: you have not addressed the relationship between the PMTM4
model and TMCL at all in this email as far as I can see. Possibly this
was because you didn't get what I thought the issue was. I'll try and
be more careful in explaining how I see this.

Topic maps are a data model[1], just like relational databases, RDF,
XML, and ISO 10303 (STEP) are. A data model, used in this sense, is
something that defines how you are allowed to build data structures.
In STEP, for example, there is something that says that data consists
of entity instances (think objects). Each entity instance is an
instance of a particular entity (think class), and has a set of
values for the attributes (think properties) defined by the entity.
There are also a set of allowed types for such attributes, and they
have a well-defined structure peculiar to each type.

The proposed PMTM4 has _two_ data models: a core model, and a model
that corresponds to topic maps as we know them (let's call it the
Standard Application in this thread). Association templates, as far as
I have understood, are used to build the Standard Application. This
means that if TMCL is to use PMTM4 association templates to define
constraints the same constraints that were used to define the topic
map data model will also be used _inside_ the model built using them.

This corresponds to having ISO 10303 use some schema language (let's
call it IMPRESS[2]) to define how entity instances are related to
their characteristics (in this case their attribute values and their
entities). The data model of ISO 10303 will then be built using
IMPRESS. ISO 10303 also has a schema language which is used to define
entities. The situation where PMTM4 association templates are TMCL
corresponds to using IMPRESS both to define the basic model, and also
to define schemas for applications of ISO 10303. This means that the
same thing that is used to say "entity instances must have entities"
would be used to describe the structure of entities.

Instead, what ISO 10303 does is to define the basic model without
using any form of schema language. There is a schema language for ISO
10303, called EXPRESS, but this works entirely _within_ the already
defined data model, and cannot change it in any way. RDF, RDBMSs,
SGML, XML, LDAP, and so on and so forth, all follow the same approach.

I'm sorry if this was hard to understand. I've done my best to try and
explain, but I find it difficult to explain clearly.

--Lars M.

[1] Note: I'm using the term data model in its traditional sense here,
    which is very subtly related to the "Help! Topic maps have no
    standardized data model" sense that has been common in our
    community so far. I try to explain in the text.

[2] There is no such schema language. I'm just inventing an example to
    make what I mean clearer.