[sc34wg3] Illustrating SIDPs

[Robert Barta]

On Tue, May 11, 2004 at 08:35:13AM -0400, Patrick Durusau wrote:
> >Robert Barta said:
> >Putting topics into equivalence classes can be more general than just
> >looking at the properties (or combinations thereof). Not that I would
> >expect TMCL to cover things like these, but consider a class-inducing
> >rule like:
> >
> > "all topics which are associated with the same number of topics (which are
> >  themselves not instances of persons) having an even number of properties 
> >  not
> >  matching particular values .........are to be regarded the same"
> >
> >Absurd maybe, but probably not expressible as function of topic
> >properties.
> >
> 
> OK, you have my curiousity up. Can you say a little more about the 
> significance of "(which are not themselves instances of persons)" in the 
> context of your example?

That "(..)" has only the significance to complicate the example. The principal
complexity comes from the "number of topics". Such statements are only
possible in the context of a particular map, so identity is not something which
is locally governed by topic properties.

> >That's my point. The lack of a proper formalism is the source of
> >confusion.  We as TM community have - whatever the history might be -
> >allowed for too long to work in fluff-space. This costs enormous
> >amounts of energy to explain ourselves to each other.  So our
> >advantage that most of us are pragmatists also may turn against us.
> >
> Just note that I disagree with "fluff-space." Whatever the history, we 
> can go forward or chew over past positions. I prefer to find new and 
> common understandings.

Disagreement with "fluff-space" duly noted :-)

> Here we depart company. This may be the question of formalism that we 
> are batting back and forth but I think to "leave identity (and connected 
> merging rules) out of the TMRM is a serious mistake."
> 
> Perhaps we mean different things:
> 
> Do you mean that the expression of the rules for identity (and connected 
> merging rules) should be left out of the TMRM? (Which you already charge 
> to be the case.)

Yes, i would take it out of the core TMRM and would try to reformulate
it with this 'low-level TMCL'.

> Robert Barta said:
> >TMRM would then capture all possible forms topic maps could
> >potentially have, without any constraint. TMRM would describe the
> >fundamental set of all possible models (in the mathematical sense,
> >now).

> Patrick asked:
> And that leaves the model and requirements for rule for identity (and 
> connected merging rules) in the TMRM?

Not in the core, no. But the TMCL could have a TMRM-specific part.

> Have you looked at Neill Kipp's formalism for the TMRM?
> http://www.jtc1sc34.org/repository/0441.htm

Yes, Graham has shown it to me in Amsterdam. A good start, but probably
not the end solution.

> There is NO, repeat NO, separate implementation requirement. You would 
> follow the TMRM model (as you allude to above as "all possible forms") 
> at the implementation level in any way you choose.
....
> Do not look at the TMRM as a competing implementation strategy and view 
> it as a model that sets forth the requirements for the rules that you 
> posit for TMCL (well, not complete coverage from what you say). Quite 
> honestly I can't see how anyone would view the TMRM as an competing 
> implementation strategy.
> 
> Yes, there has been a lot of loose talk over the years of the TMRM being 
> written about "implementations" of the TMRM. Simply not correct. One can 
> implement a topic maps application that follows the rules of the TMRM 
> but that is an entirely different thing.
> 
> For one thing, the TMRM lacks any specific rules for either identity or 
> merging. Simply not there. It specifies, albeit without a lot of clarity 
> of expression, the rules for specifying such rules. So, how are you 
> going to implement something that is only a set of requirements for 
> rules that it does not contain?

...thinking...

> >If it succeeds, then we have ONE formalism to express what a 'TM 
> >application'
> >is. And not 1 + 0.5 formalisms.
> >
> 
> Great, but as you note above, TMCL will have several syntaxes, do you 
> have an objection to there being isomorphic mappings to other formalisms 
> for expressing what a "TM application" is?

No problem with that.

> >>Yes, the TMRM deliberately lacks a syntax (at the urging of the WG as I 
> >>recall) and nothing in it compells someone to construct the identity 
> >>rules entirely in a topic map.
> >
> >This sounds like a rather cumbersome process: You would have to use a
> >syntactic structure as a topic map to define application specific
> >rules. No operators, no quantifiers, all the millions of men-years
> >developing logic systems is simply ignored.
> >
> I was not the one who urged (insisted?) that the TMRM not have a syntax. 
> If you think that was incorrect, you need to take it up with WG3.

We will see some proposals, I hope. Then we can think how this changes
our agenda.

> Not sure how you make the jump to "all the millions of men-years 
> developing logic sytems is simply ignored."

Creating a formal representation for a particular 'data structure' in
a declarative way is not rocket science (this is what is done in the
Neill Kipp paper). Defining operations on these is not rocket science,
either. Figuring out properties of can become hard, depending on the
complexity of the rules.

In any case, logicians have spent ENOURMOUS amount of work on finding
such properties and classifying structures accordingly. I would not
simply walk pass that.

> Afterall, you have said that having a "model" (in your sense of the word 
> since you seem to think that is different from how I use the word, but 
> no proof to that effect) is something on which you would base TMCL, how 
> is that different from the TMRM?

> If you don't start with a model (your sense), how do you decide what 
> rules to write?
> Starting with an unspecified model looks like a bad plan to me.

Quick explanation of "model" in the 'mathematical-logical' sense
<can be safely skipped>

If I present you the string

  "1 + (2 + 3) = (1 + 2) + 3"

then this is just a string following a particular syntax.

To give this thing a meaning you could map the symbol "1" to the
number 1, map "2" to the number 3. You could map the "+" between two
symbols to the addition of numbers.

If you use that mapping (so-called 'interpretation') and compute the
values then the above statement is true. This means that you have
found a 'model' for the behaviour you have characterized.

--

In general you have a syntactic structure (can be a string or also
a multidimensional thing) and then you define a mapping from all these
_syntactic_ constructs what they _mean_ in a concrete world (in our
case natural numbers with addition). 

If the concrete world satisfies the constraints (like our equation above)
then it is a "model" of the constraint.

> >>Stepping aside from the TMRM for a moment, recall that we discussed in 
> >>Amsterdam the need to have a "reference model" as the common basis for 
> >>TMCL/TMQL, etc., and have a workshop set for Montreal. What I would 
> >>suggest is that a "reference model" that provides the framework for 
> >>however one wishes to allocate the resolution of the identity issue is 
> >>the goal of that exercise.
> >
> >
> >I personally would love to be there, but I can't.
> >
> Why not? (serious question, well they all are but I don't want the "why 
> not" to sound flippant.)

I am suffering from the out-of-funding syndrom.

> Sure, and I was not suggesting that we should not have convenient, etc, 
> languages that are not as expressive as the model (your sense) permits.
> 
> I really think we are straining to disagree with each other by this point.

Right. :-)

> >>Why not abstract out the formalism of TMCL that is not based on 
> >>remedying that weakness and propose it to the 'reference model' 
> >>workshop?
> >
> >
> >....but have no idea what this precisely would mean.
> >
> Well, that is why we are having this discussion, correct? ;-)
> 
> I had the impression from your first post that you had the view (may 
> have been a mistake on my part) that there was a formalism for TMCL that 
> is separate from the actual rules you intend to express in TMCL. Was I 
> simply mistaken?

I am not quite sure about the question itself.

TMCL is a language which allows to define constraints C ala "a + b >
c".  Our concrete universe is the set of possible topic maps M.  A
TMCL constraint C then validates against a map m (element from M)
under particular conditions as is defined by the TMCL semantics.

I would say that we should give Graham/Dmitry and /me a bit more time
to shell out our formalism. It may be a bit easier then to show
what parts may have a relevance for TMRM.

Or not :-)

\rho