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

[Robert Barta]

On Thu, Jul 15, 2004 at 06:40:12AM -0400, Patrick Durusau wrote:
> >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?

Patrick,

Yes, no. I do not know. :-) If writing a TMCL document means to define
_what_ concepts I have and how they are related, then associating with
this TMCL statement a namespace would be a rather natural thing to do.

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

No.

To associate a namespace http://coffee.org/1.0/ with a TMCL document could be
done with a .... Topic Map. It is metadata (see below).

> 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.

It would not be INSIDE a TMCL statement but would be an association
between a TMCL document and the namespace:

# in AsTMa=

coffee-ontology is-a ontology
bn: Coffee (not beer, Lars)
oc (namespace): http://coffee.org/1.0/

> 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.

> 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.

> >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.

> >> 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.

> >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?

Yup.

> >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.

I had to give up on this as I did not understand the problem/question.

> >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?

This is on the top of the pile of my bedtime reading.

> 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.

> 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?

Yes, this is yet to be done. The background is that for practical
querying a map you definitely WANT to have some control over the
result order. At this stage I am not sure whether this should be in
the formalism or only in TMQL. So I left it out.

> 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.

> 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.

In the announcement

   http://www.isotopicmaps.org/pipermail/sc34wg3/2004-July/002326.html

I explicitely say that it is "quite TMRMish" but....

> Expressed quite differently and some difference on 
> emphasis, and you don't cover disclosure except implicitly, etc, but the 
> basic concepts are quite close.

...that are still major differences, yes.

\rho