[sc34wg3] Re: PMTM4 and XTM Layer 1.0

Wed, 3 Oct 2001 08:03:29 +0100

Hi,=20

I'm trying to follow all this at the moment and use the input to try and
see where the harmonization of a core (PMTM4) and a Higher level model
can fit together.

First, in many ways I agree with Martin Bryan when he said that it is is
important to make distinctions within the map about different pieces of
the machinery.=20

I'll explain this a little further,

I have been looking at how UML relates to RDF and TopicMaps - comparing
metamodels etc, and I've been trying to answer the question - what is
different about UML and TopicMaps.

Here are a couple of the things that I found, i think,

TopicMaps typically make the metamodel, i.e. classes and assoc templates
part of the runtime environment, UML typically never has the metamodel
as part of a run time environment. Thats because the run time env is
often java or python etc, which just dont have these features. Perhaps
the closest we get to having access to the metamodel at runtime is
something like smalltalk.

Secondly, topicmaps at the moment priviledge certain things in order to
achieve commonlaity and interchange. These things are names and identity
structures. Occurrence I can quite happily see as Assocs in the model.
Because these things are priviledge in the data model in the layer 1.0
model, there is no ambiguity about them - interchange and
interoperability is strengthened.

One concern I have about PMTM4 is that becuase everything is so regular,
these distinctions are lost from the basic data model. PMTM4 is reliant
on the fact that people interpret a Data driven model with the correct
semantics rather than the semantics of the model (when I use semantics
here I mean the ability to find a topics name etc, the ability to find
out about the topic map from the data model.) being an integral,
unambiguous, part of the model.=20

An example, if names are modelled as assocs in PMTM it requires that
there are PSIs, probably, to identify name structures, these have to be
interpreted by SW in order to impose the correct semantic upon these
regular structures. If naming is a first class principle then it should
be there as such.

Returning to the UML / TM comparison, identity is *in* UML, but it
doesnt make the distinction between resolvable topics and conceptual
ones. However, being UML it could create an class to do this - the point
is that it isnt standardised. I think this is one of the best things TM
offers the world.

Another UML reference. PMTM4 see everything as a topic, including
strings and I assume integers - this brings it very close to the UML
model that just connects Objects togther.=20

As the full PMTM4 model isnt described yet - I dont see what in a data
model a Topic now looks like :

e.g.

<topic>
	<baseName>
		<baseNameString>Graham</baseNameString>
	</baseName>
</topic>

Generate 2 topics in PMTM4

1. topic for the topic named 'graham'

and=20

2. a topic for the string 'graham'

Now, what I ask steve and michel is, how does this micro part of the
model pan out, does for example a topic have a type - like string, int,
Object, Topic?

Topic.value =3D> "graham" ??
Topic.type  =3D> "String"

I am concerned that by making everything a topic here we are getting
into a lot of other issues, such as data types etc, and if this is the
route we want to take then I think that the large similarities with UML
and the fact that it does all of this stuff already, we should consider
adapting the UML metamodel model to have the new properties of
TopicMaps.

One last question that got me started thinking about PMTM4 integration
with a higher abstraction,

in the above exmaple most people - users? - would imagine they had added
1 Topic and 1 String into the system.=20

Asking PMTM4=20

TopicMap.getTopics().size() || TopicMap.topics.length || Card(topic) ||
etc

would yield *2*

Asking a higher level of abstraction would yield *1*

At the moment I see this as a BIG stumbling block to getting a
integrated model. If I hope i've missed something obvious.

This mail has just been a question asking one which I need some thoughts
on and answers to before putting more effort into a paper on UML and
TopicMaps and the work on the ISO Data Model.

gra

-----Original Message-----
From: Steven R. Newcomb [mailto:srn@coolheads.com]
Sent: 03 October 2001 03:33
To: Lars Marius Garshol
Cc: topicmaps-comment@lists.oasis-open.org; topicmapmail@infoloom.com;
sc34wg3@isotopicmaps.org
Subject: [sc34wg3] Re: PMTM4 templates vs. TMCL (was: Re:
[topicmaps-comment] RE: OASIS vs W3C)

(I don't like the subject line of this note.  PMTM4 and
constraint languages are orthogonal issues.  There is
no "PMTM4 vs. TMCL [Topic Map Constraint Language]".
At least not in my mind.)

Lars Marius Garshol <larsga@garshol.priv.no> writes:

> 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
> |=20
> | PMTM4 merely explains how sets of constraints --=20
> | constraints that might be expressed in TMCL --=20
> | 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.

I'm surprised.  I've never heard any argument
suggesting that any that subject that is a class of
anything that's in a topic map be anything other than a
topic.  I've never heard any argument in favor of
allowing a role subject, for example, to be represented
as anything other than a topic.  Roles would have to be
accounted for in any schema for a topic map.

Surely the purpose of any sort of schema is to
establish classes of things.  For me, at least, the
idea that instances of things in a topic map can have
classes that somehow magically exist but are not
themselves topics is absurd.  The effect of such a rule
would be to prohibit the topic map from making
assertions about them: from explaining them, from
defining them, from showing other instances of them,
from subclassing them, etc. etc.  It would place these
things out of reach.  Indeed, it would falsify the
primary claim of topic maps, that literally anything
that is relevant to any subject is automatically
aggregated around that subject's identity points (i.e.,
that subject's topic).  If the classes declared by
topic map schemas are exempt from this rule, then the
Topic Maps paradigm is well and truly broken and wrong.

You claim that the question of whether a schema should
appear in the topic maps that it governs can be argued
both ways.  OK.  Please state, for the record, exactly
what are the *advantages*

* for users,

* for single authors,=20

* for sets of collaborating authors,=20

* for topic map aggregators,=20

* for topic map owners, and=20

* for topic map systems implementers,=20

of *not* establishing, as part of the Topic Maps
standard, exactly how the subjects that are the classes
established in a schema shall appear in the graphs of
the topic map that they govern, in such a way that

* these classes are topics, like any other topics, and

* these class topics are directly and specially related
  to the instances that they govern, and

* the instances of things that they govern are directly
  and specially related to the classes that govern
  them.

I'll be interested to see how you argue that these are
not fundamental requirements for any reasonable model
of what topic maps mean.  We can't make our model
account for something that isn't part of our model.

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

I think you misunderstood me.  I did not propose to
require that each constraint be the subject of a topic.
I was only making the routine observation that
constraints, like everything else, can be the subjects
of topics.

> 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?

The answer to your question is, "No.  I do not propose
that there must be a topic in the topic map that
represents this constraint."  What PMTM4 proposes is
quite different from what you evidently think it
proposes (obviously, this needs to be made a lot
clearer -- thanks for helping).  PMTM4 proposes that
the set of constraints on any role-player be the
subject of a topic whose subject is a class of which
the role-player must be an instance.

But I have some questions for you, now.  It seems to me
that your example of a constraint statement is not very
explicit about exactly what it's constraining.  Suppose
there is a topic that violates this constraint: it's an
instance of the class "country" that doesn't have a
base name in a scope that has the "native-name" topic
as one of its components.

A. Is this constraint really just a constraint on the
   class-instance association that establishes that
   this topic is a country?  In other words, does the
   existence of this class-instance association trigger
   the validity check that finds this violation?  In
   still other words, does the fact that "country"
   plays the class role require that the topic that
   plays the "instance" role participate in certain
   other relationships?  If so, I say "Hallelujah."
   This seems to me a sensible, simple, useful, and
   implementable approach, at least for the near term.

B. Or is this constraint an example of a far more
   general notion of constraint.  I'm imagining this
   "far more general notion of constraint" to be
   something like this:

     Each constraint statement imposes its constraint
     on the entire topic map.  Each constraint
     statement describes a prohibited constellation of
     relationships and/or lacks of relationships.  If
     such a constellation of relationships exists, no
     one relationship within that constellation of
     relationships is considered to be the thing that
     is violating the constraint; it's the combination
     of relationships and lacks of relationships that is
     what's being prohibited.

The B approach is tremendously more powerful than the A
approach for detecting complex problems and imposing
very sophisticated constraints.

But I still think we should start with the A approach.

If we start with the B approach, we will endanger our
chances of success.  Here, I'm speaking with the sad
voice of experience, and out of a genuine concern for
the success of TMCL.  I'd much rather we did something
relatively easy that results in a standard that
succeeded in the marketplace, than that we did
something extremely difficult that resulted in a
standard that failed in the marketplace.  It's an easy
choice to make, really.

I think we should lay an early, simple, sturdy
foundation on which we can build greater power and
complexity in the future.  I believe that the
best way forward is to begin by providing a way to
constrain the instances of relationship types.

It doesn't make sense to begin by constraining
topics.  The only meaningful constraints we could
impose on topics would be *constraints on the set of
relationships in which a topic plays various roles*.
This would be a constellation of relationships.  It
would be Approach B, basically.

We're not ready to impose useful constraints on *sets
of relationships* until we have demonstrated that we
can impose useful constraints on *a single type of
relationship*.  We must learn to walk before we can
learn to run.  Once we can constrain specific
relationships, we'll be in a position to impose
constraints on sets of relationships.

> | * recognized player of role classes are topics  <<-- this is the one
> |                                                   we're talking
about.
>=20
> This is only true while you are wearing PMTM4 spectacles.
> Non-believers don't see it the same way.

I hope you're not intending to imply that PMTM4
distorts one's vision of what topic maps mean, or that
PMTM4 represents some sort of religious dogma that
beclouds the minds of its adherents.

I shouldn't complain about your remark, though, because
it has inspired me to say a few words about my own path
to true enlightenment (for me, enlightenment is, of
course, PMTM4). =20

I have always thought that topics were what topic maps
were all about.  And it's true that topics are what
topic maps are all about!  Furthermore, there are
millions of people who can understand topic maps
precisely because the topic-centric view is very close
to their own established patterns of thought.  I myself
am such a person.

But the topic-centric perspective on topic maps does
not by itself reveal the fundamental simplicity of the
structure of topic maps.  It conceals the fact that
topics are *related* to their names, and they are
*related* to their occurrences, in exactly the same way
that they are *related* to other topics.  It conceals
the fact that there is a fundamental and necessary
distinction between subject-constituting and
subject-indicating resources.  It conceals the fact
that scope is only and entirely about relationships.  I
know that it conceals these things because I didn't see
them for years, and, believe me, I was looking!  (If
this confession reveals that I'm not really very
bright, so be it.)

There is another perspective on topic maps that is at
least as valid as the "topic-centric" perspective: the
"assertion-centric" (or, if you prefer,
"association-centric") perspective.  PMTM4 reflects the
assertion-centric perspective.  Topics have
characteristics because of the assertions that give
them those characteristics.  Topics themselves are
nothing more or less than nexuses -- arbitrary
addressable pieces of subject-indicating or
subject-constituting information -- about which
assertions are being made.  The assertions are where
all the action is.  The assertions are the roads on the
map.

I came from the topic-centric perspective to the
assertion-centric perspective.  That's why PMTM4 is,
for me, enlightenment.

Many others are different from me.  They have found the
Topic Maps paradigm incredibly liberating because it
has brought them from an assertion-centric perspective
(such as the RDF perspective, or a hyperlink-centric
perspective) to a topic-centered one.

True enlightenment is to fully grasp and enjoy both
perspectives simultaneously.  *Both* perspectives are
*essential*.  The question, "Are topic maps about
topics, or are they about assertions about topics?" is
really a waste of time and energy.  Which brings me to
my dark suspicion.

I suspect that the real issue about TMCL boils down to
this:=20

  Should TMCL begin by supporting the topic-centric
  perspective or by limiting its initial support to the
  assertion-centric perspective?

Ultimately, we must have one or more constraint
languages that will serve both perspectives.  You'll
get no argument about that from me.

All the same, it's very clear, at least to me, that we
must support the assertion-centric perspective before
we can support the topic-centric perspective.

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

No.  First of all, PMTM4 is the core model, full stop.
True, it has a couple of association templates in it --
but only the ones needed to define association
templates.  Yes, this is recursive.  No, this doesn't
cause a problem.  It's merely a bootstrap technique,
and it works.  It's analogous to using a C++ compiler
that's written in C++ to compile itself.  It's done all
the time, and it's a very good practice, for many
reasons.

We have also proposed that we standardize certain
association templates as the Standard Application.
These templates are not part of PMTM4, and PMTM4 does
not depend on them.  If PMTM4 is adopted, the Standard
Application, and all other applications, will depend on
PMTM4, but not the reverse.

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

I appreciate what you're saying, I think.  The topic
maps paradigm is different from all these other
standards and formalisms.  It claims to do -- and it
actually does -- something that none of these other
approaches were attempting to do: provide a unifying
framework for literally *all* assertions about
literally *everything*.  Therefore, the paradigm must
"eat its own dog food", as the dreadful expression
goes.  The Topic Maps paradigm must fully encompass
knowledge of itself, in a fashion which is completely
consistent with its encompassment (if that's a word) of
every other kind of thing, and, at the same time, in a
fashion which reflects the special issues surrounding
detailed self-knowledge.

PMTM4 shows how Topic Maps eats its own dog food.  So
far, I don't believe anything else that has been
proposed truly does.  I'm open to the possibility that
another model can also do this trick.  I'll certainly
resist the adoption of any model that doesn't eat the
dog food.  If nothing else, PMTM4 demonstrates that the
dog food can be eaten.

-- Steve

--=20
Steven R. Newcomb, Consultant
srn@coolheads.com

voice: +1 972 359 8160
fax:   +1 972 359 0270

1527 Northaven Drive
Allen, Texas 75002-1648 USA

_______________________________________________
sc34wg3 mailing list
sc34wg3@isotopicmaps.org
http://www.isotopicmaps.org/mailman/listinfo/sc34wg3

_____________________________________________________________________
This message has been checked for all known viruses by Star Internet
delivered through the MessageLabs Virus Scanning Service. For further
information visit http://www.star.net.uk/stats.asp or alternatively call
Star Internet for details on the Virus Scanning Service.