[sc34wg3] Re: FYI: Yet another TMRM Formalization (well, not really)

[Patrick Durusau]

Robert,

Impressive! Comments and questions follow:

Robert Barta wrote:
> On Wed, Jul 14, 2004 at 02:13:59PM +0200, Jan Algermissen wrote:
> 
>>Robert Barta wrote:
>>
>>>On Wed, Jul 14, 2004 at 07:24:08PM +1000, Robert Barta wrote:
>>>
>>>>Hi all,
>>>>
>>>>FYI, this is our current working paper here to capture "the essence of
>>>>TMs".
>>>
<snip>

> 
> 
>>- In assume that all names come from a single namespace, right?
> 
> 
> Flat, yes.
> 
> 
>>  What about the
>>  literals? If you use literals for the purpose of identity, all literals
>>  must also come from a single namespace, or they must carry around with them
>>  an implicit namespace. OTH, you say they don't, they are just numbers or
>>  quoted strings. So, how does "grroop" provide identity?
> 
> 
> Literals have an identity. "grroop" is the same as "grroop" and
> different from "Rumsti". If I need name spaces, then that would
> eventually be mapped to a flat set anyway. So why make things
> complicated in the beginning?
> 

Namespaces would be handled in TMCL?

If yes, would you see the reference model as requiring namespaces to be 
specified in TMCL?

The reason I ask is ascertain where disclosure requirements reside in 
your proposal? I am assuming that from what you have said, those would 
be in TMCL, which looks like an unlikely location.

Reasoning that TMCL would give one the ability to impose whatever 
constraints are thought necessary but would not impose a requirement 
that particular constraints be expressed.

And if TMCL is the mechanism for such constraints, such as requiring 
namespaces, where is the requirement for namespaces expressed? (I am 
assuming that namespaces are necessary for the merging of topic maps 
governed by different TMCL expressed constraints. Or some similar 
mechanism.)

<snip>

>>- Why are the names in a special collection they are also just literals, or?
> 
> 
> The trick is that members contain a pair < r, p >. r is a name, p is either
> a name or a literal. < basename, "Jan" > would be an example.
> 
>

Can you say a bit more about the identity of the "p the player of the 
member?" Is its identity determined by a single identifier or can it be 
an arbitrary combination of identifiers? (members of your set "I")

>>1.3:
>>
>>- You write that "we do not want to build in any particular merging rules into
>>  our model at this stage,..."
> 
> 
>>  You are proposing an assertion model that allows a single role to be played
>>  more than once
> 
> 
> Yes.
> 

Shouldn't your answer be maybe? ;-)

Assertion models being defined in TMCL?

<snip>
> 
>>  and while this seems fine now[1] I promise you that the problems will
>>  immediately arise when you try to *implement* merging (which requires to
>>  detect assertion equality, which is hard to do efficiently in the case of
>>  multiple role players[2]). 
> 
> 
> <evil-laughter>Har har har</evil-laughter>.
> 
> In my opinion merging __on a formal basis__ should not be in a model
> with this abstraction. If I want to merge
> 
>      "two people with the same birthdate and the same name and the
>       same country of origin, but only from middle east countries"
> 
>    [ that actually happened, the man was arrested in the US ]
> 
> then this does belong to a TMCL.
> 
> This is NOT about efficient implementation. If I ask you to model the
> natural numbers, {1, 2, 3, 4, .....} then you would have no idea how
> to implement them unless you know what the agenda is: finding a
> particular prime. The agenda determines your choice for implementation.
> 

+1 on not defining efficient implementation at this level.

Actually there are more complex problems in modeling terms when one role 
appears more than once in an assertion but as you say that is a problem 
one faces in designing the constraints. Won't divert from your proposal 
to discuss that here.



<snip>
> 
>>  In fact, the RM enables you
>>  to write a mapping TMA between yours and the TMDM.
> 
> 
> I cannot see this. I know that this was the intention, but the TMRM
> never had any formalism, language, .... to actually express a TMA. It
> had only the framework. As I had mentioned earlier, this is like
> building houses without a roof.
> 

Same criticism applies here. You have an imagined future formalism, 
TMCL. Let's all concede that we need a formalism to express 
constraints/TMAs and roll on shall we?


> 
>>  Rather simplified you can also put it that way: The RM enables
>>  the definition of TM schemas and your paper defines such a
>>  schema, just not in RM language (in essence: TMA == Schema).
> 
> 
> For this argument I would see the \tau model at the same level as
> TMRM. It does not predefine any 'application-specific' names and
> also not a single rule.
> 

Agreed.

> My thinking is that a TMA is nothing else as than a proper TMCL
> statement.  Here I would define
> 
>   - what kinds of things do I have,
>   - how are they structured (properties, ....)
>   - what is my understanding when two things are the same
>   - what app-specific rule must they follow....
> 
> If TMCL is based on something which is compatible with the \tau model,
> then that would cover the TMA relationship you, Patrick and Steve,
> et.al.  envisioned.
> 

But at some point the rules for disclosure have to be defined. Reasoning 
that it is well and good for a TMCL statement to do as you suggest but 
at some point I need to know what I am required to state. If an external 
entity is going to be resolved by my SGML parser, there is a specific 
"disclosure" procedure I must follow in order for that to happen.

> But it would have a language and a sound formalism. That's the
> difference for me. The TMRM, as it stands, is very difficult to digest
> for outside people (withholding 3rd party comments here).
>
Did you find the more recent narrative any better?

> 
>>I hope this clarifies matters a bit. If my language sounds too
>>offensive, please take my apologies, I do not mean to sound rude.
>>I maybe just got carried away by the issues.
> 
> 
> Ah, I *always* prefer men with passion and vision over those with
> overpolite poker faces. The latter always survive but they ruined
> the planet.
> 

+1 here as well. I am listening to some of the music from Fahrenheit 
9/11 right now.

A couple of extra questions:

1. "literals"

You don't say how the pairs of objects and literals arise. I assume that 
is intentional? (Thinking here of the TMRM's distinction between 
built-in versus conferred properties.)

2. Ordering

In 2.1 Tuple Matrixes, second paragraph, you mention:

"This covers another, important requirement for the language, namely 
that the results should be deliverable in a particular order."

I am not claiming to have worked through the entire paper with paper and 
pencil but so far I don't see the rationale for that. Oh, is that to be 
covered in .6 Ordering? That is to say, not proceeding from ordering but 
a justification for ordering?

3. Identity

So, I take it that the \tau model does not constrain, although a TMCL 
statement might, a topic map from defining the identity of a topic from 
consisting of more or less than is expressed in the TMDM?

Thinking here of the use cases Newcomb and I prepared that revolved 
around different ways to define identity and not forcing data into a 
particular syntax.


General comments:

Despite your claims to "now for something completely different," I
really don't see much that is inconsistent with my understanding of most 
of the TMRM. Expressed quite differently and some difference on 
emphasis, and you don't cover disclosure except implicitly, etc, but the 
basic concepts are quite close.

None of that is to take anything away from a quite clever and sometimes 
clear, ;-), presentation that offers us a lot to think about betweeen 
now and Montreal.

Hope you are having a great day!

Patrick

-- 
Patrick Durusau
Director of Research and Development
Society of Biblical Literature
Patrick.Durusau@sbl-site.org
Chair, V1 - Text Processing: Office and Publishing Systems Interface
Co-Editor, ISO 13250, Topic Maps -- Reference Model

Topic Maps: Human, not artificial, intelligence at work!