[sc34wg3] Modularization

[Michel Biezunski]

* Lars:

> Well, the first thing it requires is to understand what you are
> proposing. I'm afraid I still don't get it. Can you be more specific?
> Do you want the RM to change?

Yes.

> If so, how?

By making the SLUO and the assertion structure two separate
sections that integrate in different parts of the revamped
topic map standard.

> Do you want the SAM to
> change? If so, how?

Yes. By making the conceptual model, the syntax, and the
API requirements separate sections that integrate in different
parts of the revamped topic map standard.

> Should we take out some sections?
> Add some new
> ones? Remove a document? Add a document? Change the formalism used?
> Not use a formalism at all?

I don't think the formalism is a major issue. But the organization
of sections and how each of them fits into the standard are certainly
impacted by this discussion. I don't think we have arrived at a
consensus yet. I am working on achieving this goal and to have
the various parties agree on a solution which will
eventually be considered satisfying from all diverse points
of view.

> It seems to be clear in your mind what you want, but I can't for the
> life of me work out what it is. I'm afraid you'll have to be very
> concrete and specific for me to understand what you mean.

I am trying.

> | [the 4 main aspects] should be defined in a modular way, so that we
> | know which are the ones which are being referred to and implemented
> | in certain application models and certain applications.
>
> What does this mean? How do the current drafts fail to do this?

At the same time it constrains too much application design
and it is doesn't enough define the foundations on which it
is built. We need to, we can, do better on this.

> | There is no necessity to have them all implemented in all
> | applications.  But at least we need to know what is where. This will
> | help topic map users to choose the application they need depending
> | on their requirements.
>
> So you are saying implementations should be allowed to not implement
> parts of the SAM model, or parts of the XTM syntax?

Yes. I can imagine for example a topic map application which does not
know anything about scopes. Or another one which doesn't allow topics
to have multiple names. Or another one which doesn't implement the SAM
at all but is still compliant at a deeper level (i.e. results in a
compatible graph model).

> | This situation is potentially risky because the more we add layers
> | (TMCL for example) the more sophisticated and complex the
> | applications will become, the more difficult it's going to be to
> | de-intricate what's fundamental from what's specific, and we are
> | going to create a situation where we will only be able to process a
> | narrow universe because the model is too much defined [...]
>
> So what do you propose that we do? Without knowing what you want to
> fix I can't say I even understand your concern.

Modularize, so that each application can declare what are the
parts that are implemented and what are the parts which are not.
For example, it looks to me perfectly valid to have applications that
only implement what is currently called the SAM. It's actually the
bulk of existing applications up to this day and that's fine with me.

> | A standard can not be built like a software application. Yes, there
> | is a need to support existing software applications and I don't
> | think anybody denies that. We need to make sure that the existing
> | software applications that are able today to define themselves as
> | topic maps compliant will still be able to do so in the future even
> | if it requires perhaps some minor adjustments.
>
> This isn't what the SAM is about at all. I am not sure why you are
> saying this.

The SAM is describing the way currently available applications work,
or should be working. TMCL and TMQL will add extra layers on those types of
applications. This is fine, but this is only a given universe. This
universe is interesting, but it's not the only one there is. I want
to leave room open for defining other kinds of applications. Some of
them I don't know them now. But I know for a fact that we can't possibly
have thought of every type of application past, present or future that
will have some relation with what we call topic maps.

> | The difference is that a standard must be enabling, i.e. it must
> | accommodate some space for applications which are not necessarily
> | following the models used by today's existing applications. This is
> | I think a necessary condition to ensure long-term viability for the
> | standard. The level of abstraction of the standard must be higher
> | than the level in which applications are being designed.
>
> Well, Michel, this is a tricky question, I think. The whole purpose of
> a standard is a draw a line between conforming and non-conforming, so
> that one can have interoperability of data and applications. I am not
> clear on exactly what you mean here. Do you mean that we should
> require applications to support a differerent model?

Not require. Enable. That's the whole point.

> That we shouldn't
> require them to support anything at all? Or what?

No. Precisely my point is that there is a common underlying foundation
to topic maps that is more abstract and more encompassing that the way the
SAM is currently designed for. The two main points for me is:
connect and merge knowledge. Everything that aims to do that should
be mappable to the topic map foundation and should be describable
as topic maps.

> I should probably make it clear that in my opinion conformance in the
> new 13250 should go something like this:
>
>  - software may conform to any subset of the parts they wish,

Yes, and the parts should be clearly identified so that a potential
buyer can look on the box and decide whether the features it covers
meet their needs. That's how I think it should end up working. When
you buy an electric appliance you look for the voltage. Same thing
here.

>  - SAM conformance means to expose an API that contains all the
>    information in the SAM with an equivalent structure, and providing
>    more information is explicitly allowed,

Exposing an API is different from defining the concepts and
defining a model. That's a key point in this discussion. This is
why I am asking to break the SAM in parts where what belongs to
the model is made distinct from what belongs to exposing the API.
It's similar to the difference between syntax and concepts, although
a little bit different.

>  - XTM conformance means being able to import and export XTM documents
>    in conformance with the syntax spec,

Yes, and also we should know until which level of precision the
subjects that constitute the information should be defined.

>  - HyTM ditto.

Yes. But I don't think we can achieve the same level of precision.

> Does that fit what you are thinking?

See above.

> | On the one hand, one of the problems I see with the SAM as currently
> | defined is that it's too precise in the sense that it implies a
> | given type of API.
>
> What do you mean by this? Do you think it should be changed to allow
> other "types of API", whatever that may mean?

It's a question of abstraction level. I think the one we have is
too specific. We need one level higher.

> Do you think we
> shouldn't have a precise definition?

No. On the contrary. I think we should be more precise than what
we are now. But less specific. It's not contradictory. But it's
subtle.

> Come on, Michel! Obviously there
> is something you want to say. Please say it!

I am actually saying what I have to say. If you have other questions, please
ask.

> | I do not deny the interest of having had to do so in order to
> | understand what we are doing and we have to be very grateful to the
> | current implementers who are sharing technical information about the
> | way they have implemented things. This is extremely useful but we
> | should use this to build the concepts in a way that takes some
> | distance from what has been made available.
>
> You've got this backwards. Current implementations are the way they
> are because XTM 1.0/ISO 13250:2000 required them to be that way. The
> SAM simply reflects what was in XTM 1.0/ISO 13250:2000, not how
> implementors want other implementors to do things.

When the standard was designed, there were not a lot of applications
out there. There were less experience, and we couldn't anticipate
all of the potential zones of fuzziness and of misunderstanding.
We tried, and I think we did the best we could. Now it's time for
maintenance taking into account the experience gained. We must
retain compatibility with what is already there. But we have to
improve the standard and make it fit better at the same time the
current implementations but also make room for future ones. I am
not saying it's easy. But this is a condition for being present
over the long-term. The current standard is not sacred. What needs
to be preserved and extended are the underlying ideas (as well as
maintaining backward compatibility of course, needless to say).
The current state of development of applications is only one
element of the equation, it can't be all there is. In other words,
we are entering a new period, we have to use this work which is
currently taking to position our standard for a longer term and
consider what has changed in the world since we have published
the first version.


> | On another hand, the approach taken by the RM has also its
> | drawbacks. The RM doesn't distinguish clearly enough the "subject
> | location uniqueness objective" which is the basic principle that
> | underlies the very nature of what topic maps are from the assertion
> | structure mechanism (all the business about the types of nodes and
> | arcs). For that reason, the RM looks like a big monolithic set of
> | stuff that looks entangling and extremely constraining (why the hell
> | do we need to go through all this ordeal?), and it has the effect
> | that some of the software implementers see it as something
> | astronomically costly in terms of guaranteeing compliance. I believe
> | that this problem could be overcome by separating what the reference
> | model brings to topic maps in several parts that need to be
> | integrated at completely different levels in the forthcoming new
> | version of the standard.
>
> This is the only part of your posting I can understand. It's vague,
> but still understandable.

Thanks.

> | What I propose therefore is to redefine the building blocks that
> | will facilitate building the kinds of applications the market is
> | looking for. So now to answer your question, what I am proposing is
> | not different from anything that has been developed both as part of
> | the RM and the SAM, but I propose to organize the building blocks in
> | a clearer, more harmonious, better integrated, way.
>
> Great. Which way?

First step: Agree that this is a useful step. You seem to be saying
yes. Hopefully you are not going to be the only one. Then let's put
everything on the table. I don't have a solution ready, I
want everybody to participate and be sure that all existing and
ongoing work will be covered. This is a collective work we are
doing. My point is: folks, please, come to the same table, stop
trying to exclude others from participating, stop thinking one guy's
solution is all we have. And that the one that screams more loudly
will eventually be the only one that wins. We need to recognize
the value of what others are bringing, the existence of different
markets, the fact that there is not *one* topic map market, but
several submarkets. And that's good. It only means topic maps
are real.

> | [extensibility]
> |
> | It is the possibility to regard as a TM application some application
> | which is not in XTM (I am not speaking of XML namespaces here). For
> | example, it's possible to regard HTML documents as topic maps if the
> | meta tag contains information that can be used to derive base names.
> | If we enable that, the Web becomes a gigantic, already existing,
> | topic map.
>
> Now you've really confused me. If you build a tool that maps existing
> HTML documents to topic maps isn't that all you need? Why do you have
> to write the standard in such a way that HTML documents can be seen to
> conform to it? I don't see that the standard has any role to play
> here, except to define clearly what structure and semantics topic maps
> have.

It's already not negligible.


> | [xxxML -> SAM mappings]
> |
> | Yes, but what about a mapping between XFML and another one (XIL?).
> | There is no reason a priori why the SAM should be at the center.
> | Especially if the applications invent concepts which have no
> | equivalent in the SAM. Then what would you do?
>
> If someone wants to map XFML to XIL they are not dealing with topic
> maps, so I don't see any reason why we should concern ourselves with
> what they do.

What matters is that they are answering the very same business problem
that topic maps are designed for. I want to be able to say that topic
maps can handle it, that topic maps is actually the common ground
on which these mappings can be done. The benefit is a greater universe
of interoperability. I have the exact opposite view than you on this.
It matters. My goal is to improve interchange of knowledge and to
preserve diversity at the same time.

> * Lars Marius Garshol
> |
> | Yeah, but it won't be topic maps. When you write software you'll
> | have to either implement the SAM, or not implement it. If you
> | implement RDF you've implemented RDF, not topic maps. If you
> | implement the RM you've implemented the RM, and not the SAM.
>
> * Michel Biezunski
> |
> | This is where we differ fundamentally.
>
> I think you are right about that.
>
> | For me, it can still be topic maps, at least in certain
> | circumstances. For example, an RDF application as such doesn't mean
> | anything except for the fact that it is represented with the RDF
> | syntax.
>
> Wrong. It means it follows the RDF model. There are many RDF syntaxes,
> and you don't have to use any of them. I use RDF quite often, but
> hardly ever touch the syntax.

OK. But if you replace syntax by model, what I am saying still holds.

>
> | There is for example a calendar application using RDF. This one has
> | not a direct relation with topic maps (not even sure but let's say
> | temporarily it doesn't). Other applications of RDF are annotation
> | managers, topic-based navigation systems, graphs of associations
> | between subjects, these are genuine topic map applications. They
> | just happen to be expressed with a different syntax, but what they
> | are doing is exactly the same kind of thing we are describing as
> | topic map applications. Why should we prevent ourselves to regard
> | them as actual topic map applications?
>
> We don't. If you construct a mapping from RDF to topic maps (as I have
> indeed done and implemented and use very often) you can use RDF data
> in your topic map system. You don't have to construct the standard in
> such a way as to make RDF a conforming topic map application. The role
> of the standard is to define what topic maps are, and those building
> solutions can then work out various ways to get to topic maps from
> other information standards.
>
> The standard itself can't possibly do that job for all other
> information standards, and it doesn't need to, so long as it clearly
> defines what topic maps are.

This is an interesting point of discussion: What is the limit between
what applications are doing and the span of the standard? I see us
differing on this one as well as on other parts, sometimes you are
on the side of willing to make too much for my taste, sometimes too
little. Which means that this a good subject for discussion, and I
think that the way to progress on this issue is try to get a more
abstract view on what we are saying. This is my whole point.

Michel
===================================
Michel Biezunski
Coolheads Consulting
402 85th Street #5C
Brooklyn, New York 11209
Email:mb@coolheads.com
Web  :http://www.coolheads.com
Voice: (718) 921-0901
==================================