Consistency and Formal Model Re: [topicmapmail] Can a resourceRef be a topic

[Bernard Vatant]

Sam

> [1] "A formal model is needed" does not mean "a formal model is needed
> that...". *A* formal model does not mean *this* formal model. This or
> any model must be justified in terms of the topic map paradigm, not the
> other way round. If it doesn't meet that criterion, another formal
> model may always be chosen.

I understand your point. But the "terms of the topic map paradigm" will remain fuzzy and
lead to endless debate until they are expressed in *some* formal model that will anyway
make some cutting choices on critical issues, if it has to be formally consistent. This
model must of course be agreed upon by those who legifer on the specification, that is
ISO/IEC JTC1/SC34. And I completely agree that it could be *any* model, as far as it is
formal, internally consistent, and agreed upon.

> [2] The mathematical model, being purely formal, describes a topic map
> using purely mathematical constructs. Math has no notion, and can have
> no notion, of anything that we would call "semantic inconsistency"
> (where "semantics" includes meaning as humans understand it.)

Let me try to make it clear again in what sense I use "semantic consistency" in that
context.
It has somehow to do with human interpretation to begin with, but it can be checked by the
model in a formal way.
It is a two-stage process:

1. Declare that "out there subjects" (in every sense of the topic map definition) are
correctly represented by model objects (including relations), and that such type of
subjects is represented by such type of objects etc.
That is the "agreement on the choice of a model" - the typical work of a standard
specification.

2. Respect afterwards the rules and constraints of the agreed-upon model, and accept that
what is non consistent (mathematically speaking) with those rules and constraints is non
conform to the model.

In such a framework, an inconsistency is whatever set of relationships I have asserted
about the subjects, outside the agreed-upon model, in whatever form: natural language,
graphic, XML syntax, and that leads to a *mathematical inconsistency* when put in the
model (like: such element both belongs and does not belong to such set). It's what is done
in ontologies AFAIK, when checking e.g. if there are no loops in class-subclass
relationships.
I can't assert at the same time "Humans are a subclass of Animals" and "Animals have the
right to kill and eat each other" and "Humans have not the right to kill and eat each
other". Somewhere is an inconsistency. The model will not declare which of the assertions
is/are right or wrong, if any. It will simply say that the set is not consistent. That is
an example of what I call "checking semantic inconsistency"

To go back to the example that started the thread: It seems conform to all current rules
of knowledge representation that individual objects and universal classes (types) are
separate generic types. If Sam Hunting is declared as an individual object, it should not
be used as a type. The model has to allow the implementation and checking of such rules.

If I add "semantic" to "inconsistency", it's because the model I have in mind deals with
semantic layers, and one fundamental constraint is that an element can't belong to two
layers at the same time - which is the same kind of constraint that forbiding a loop in a
class-subclass relationship.

There again, maths can't tell you what the semantic layers *are*. But once you've agreed
upon the fact that there are such things as distinct semantic layers, you have to choose
for each object to which layer it belongs, and keep consistent afterwards. The model can
effectively help you to do that. Of course if you don't agree that topic map paradigm is
consistent with the notion of semantic layer, or if the very notion of semantic layer is a
"stovepipe", then forget it ...

> "Frobnostification," for example, could replace "semantic
> inconsistency" with no loss of formal precision -- both are a "prose
> add-on"s to the formalism, and no more or less formal than the prose of
> any standard or specification.

I disagree. As I told you a few days ago in a more private forum, "Frobnostification"
could replace any term used inside the model to name objects and relations. But "semantic
consistency" has something to do with the way you use the model. It's different, it's not
inside the model. Of course you can call things as you like. Language is a moving place,
but ... somehow we communicate, eventually ;-)

> "Frobnostification," in fact, would be more precise than "semantic
> inconsistency" in that it would avoid introducing an implicit
> functional specification into a formal model.

Wrong. It's not a functional specification of this particular model.
Consistency is a basic rule for the use of *any* model. In physics, it has a variant
called *experimental falsification*.
And a good model is a model that can be falsified ...

> That is, the label "inconsistent" is used to deprecate or forbid
> certain results of the intersection of *this* formalism with certain
> applications of the topic map paradigm.

Yes. I assume that completely. Because I really think that without formal model, you can
interpret topic map paradigm to produce junk topic maps. If you want to keep the paradigm
completely open, because you don't want to legifer on what is junk and what is not, say
that the model will define topic maps conformant to it, as a subclass of more generic
objects. As a matter of fact, if you look closely at the model, you will see that it
allows itself different subclasses (for example stratified or not).

> The reasons for such deprecation may be good, and may be bad, but
> whether they are or not, they have to do with how topic maps function
> in practice, which cannot be derived from the formalism.

Not sure what you mean by *in practice*. But if you choose a model at some point, the
practical consequences (is my topic map valid or not?) are derived from the formalism.

> 3. "Semantic stovepipes" is my label for the danger I see in the
> implicit functional specification of "frobnostification" in the
> documentation for the formal model.

There is nothing implicit there. The advantage of a model is to make the issues very
explicit.

> The danger is that the very sort of knowledge interchange that topic
> maps should be encouraging will be decreased ("islands of markup" all
> over again).

Ha! *Global* knowledge interchange, that is? For myself, I prefer to get islands of
communication inside the shores of which I know that understanding stands upon common
definition of terms, that an ocean of so-called interoperability where people just believe
they agree, when speaking of completely different things with the same apparent language.
Agreement based on contradictory interpretations of the same document is worse than
acknowledged disagreement which leads to further discussion. For example, a very
interesting consequence of the model, is that you will be able to check if two maps have
declared semantic layers consistent with each other, before merging, and if not, be aware
that this merging will certainly not make sense, even if syntactically possible.
And send that back to both authors, pointing to where they disagree, and that if they
really want to interoperate, they have to do something about it.

> Of course, "in danger, opportunity." It may be that what Bernard and
> his  team of mathematicians have come up with is a way to define what a
> "topic map application" is, which would be a fantastic result.

I'm not sure what you mean by a "topic map application" there. And just a precision. It's
not *my* team by any means, just a team that happened to delegate me as a go-between with
the dangerous outside world.

> I eagerly await the readable explanation of the model (which is very
> exciting, interesting work).

Thanks. Be patient.

Bernard