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

[Patrick Durusau]

Robert,

Robert Barta wrote:
> On Thu, Jul 15, 2004 at 06:40:12AM -0400, Patrick Durusau wrote:
> 

<snip>
> 
> 
>>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.
> 
> 
> I do not quite understand this sentence.
> 
What I was trying to say, perhaps in a clumsy fashion, was that in order 
to have disclosure, we have to say what must be disclosed.

For example, you refer below to topic maps that follow the SAME TMCL 
statements. How am I to determine that two (or more) topic maps follow 
the same TMCL statements?

That is to say, I can look at any topic map and determine everytime, 
what TMCL statement it follows?

That would be one example of a disclosure requirement.

> 
>>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.)
> 
> 
> Well, I would not adhoc see any necessity to provide a mechanism INSIDE
> a TMCL statement to hold a namespace identifier, although adding one is
> not a problem.
> 
> I am not sure why you connect the merging of two maps with namespaces.
> If you have two maps which follow the SAME TMCL statements, then you
> merge them simply, whereby the TMCL statements provide the application
> (which cares, that is) with the information what should be regarded the
> same or not.
> 
> If your two maps DO NOT follow the same TMCL statement, so that the
> maps are incompatible, then one (or both) maps have to be transformed
> into forms which are compatible. Transformations (also virtual ones)
> you can do with TMQL.
> 
> That way the process is very controlled and controllable.
>
But cf the question of how do I "know" two topic maps are following the 
same TMCL statement.


> 
>>>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")
> 
> 
> No, this is ONE thing, not a set.
> 

So, how does a subject, whose identity may be determined by more than 
"ONE thing," have its identity expressed?

There is another problem, one which I think is more responsible for the 
difficulty of the TMRM than:

> I think that you (and Patrick and Steve...) 
> tried something which is extremely hard, namely to provide a
> parametrized identity framework based on properties without actually
> saying how this is supposed to be done. This makes it hard, hard to
> write and hard to read.

;-)

When you say that members contain a pair <r, p>, it has a certain 
simplicity that is attractive but there is a problem.

Let's start with <r, p>.

I assume that 'p' represents a subject, in the sense we use the term in 
TM land?

Well, what if I want to talk about the subject of the relationship 
between "r, p"?

Note, not talking about 'r' or 'p' but the relationship between them.

And, if I can talk about that, I can also talk about the relationship 
between the two tokens that arise from that relationship, and so on.

The problem as I see it, is that in normal speech and even in viewing 
examples, we all elide over subjects that are not really relevant to the 
current conversation. That is to say that at some level, we realize 
there is a subject of the relationship between <r, p> but we don't 
express it because it does not seem to be relevant to the current 
conversation.

The danger in that elision, however, we may arrive at a system that 
inhibits statements about subjects that we elided over in the design.

Personally that is how I view the notion of subject identity as treated 
in the TMDM. For my part, subject identity (we can all thank Steve 
Pepper for the more meaningful and not to mention pronounceable, SIP, 
subject identity property) must be wholly left up to the topic map 
designer. To do otherwise, is to privilege some notions of subject 
identity over others, which TMAs may well do, but which ultimately 
limits the reach of topic maps.

Note that most syntaxes will make those choices in advance and properly 
so. That will allow them to be optimized for particular areas and I see 
no reason why that should not be allowed.

> 
>>>>You are proposing an assertion model that allows a single role to be 
>>>>played
>>>>more than once
>>>
>>>
>>>Yes.
>>>
>>
>>Shouldn't your answer be maybe? ;-)
> 
> 
> Maybe. :-) As I mentioned to Jan already, we did not see the necessity
> to hard-code this into the formalism. If we need it later (and I like the
> cleanness of the idea), then we can easily add it.
> 
We may be using the terms formalism and formal model differently. Are 
you saying that that \tau model is a formalism (means of expression) or 
a formal model (means of expression + somethign being expressed)?

<snip>
>>
>>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.
> 
> 
> I had to give up on this as I did not understand the problem/question.
> 

For example, the TMDM has rules for merging of topic information items.

If I use another set of rules for merging topic information items, am I 
required to disclose those in a TMCL statement?

What if I took the route that Kal does and have implied topics? Part of 
the software and I suspect you get different behavior/capabilities from 
Kal's software than software that does not have that ability on the same 
topic map.

Note I am not arguing about where that disclosure should take place, but 
that it should take place.

<snip>
> 
>>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.)
> 
> 
> Yes. This is a postulated set.
> 
> 

Ok, so are you planning on saying how the postulated set arises?


<snip>
> 
> 
>>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?
> 
> 
> A topic map cannot define any identity by itself (unless we use
> trivially subject identifiers there). It is the ontology definition
> (with TMCL or whatever) which introduces an identity concept *FOR A
> PARTICULAR* application.
> 

So you are saying there is no general notion of identity?

That is to say if I wanted to return to my issue above of the identity 
of a subject being defined by more than "ONE thing," your most likely 
response is that such rules for identity are defined elsewhere?

That is to say that the reference model only says that subjects have 
identities and those are defined for particular applications?

(Not arguing the point, just trying to be clear about what you are saying.)

<snip>

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!