[sc34wg3] a TM Application Definition example

[Robert Barta]

On Thu, Apr 24, 2003 at 09:00:51PM -0500, Steven R. Newcomb wrote:
> Robert Barta <rho@bigpond.net.au> writes:
> 
> > Do you think it would be possible to have a more
> > concise notation for a TMA definition?
> 
> I hope so.  Do you have any ideas?

Well, no, yes.

The reason why I was asking for a more concise notation was that I did
not understand what is going on. As a human (sort of) implementer this
is too little prose, as a formalist this too much prose.

I don't know, for instance:

1) as a TM in AsTMa*:

  IS13250-HTTPGET-1.1::PR_httpAddress ( string sidp )
  bn: IS13250-HTTPGET-1.1::PR_httpAddress
  in (description): blablabla comment
  in (value) : ?is_rfc2396

  (is-merged-using)
  property : IS13250-HTTPGET-1.1::PR_httpAddress
  method   : merged-by-taking-one
  match    : value-equivalence  

And then define the ontology behind 'merged-by-taking-one',
'value-equivalence', ...

2) as mathematical structure? Graph with labels?

3) as an incarnation of any semantic network of the last 20 years?

[ BTW: the phrase "whenever two or more topics both exhibit" sounds
  a bit weird. ]

If the whole description then collapses onto 2-3 pages, it is probably
easier for an outsider to see the wood behind the trees. Especially
sentences like (TMM#4.2.2.1.1)

  "The value is a composite that comprehensively specifies the
  relationship that is subject of the a-topic, in order to support the
  automatic determination of whether the subject is the same as, or
  different from, the subject of any other a-topic, in accordance with
  the Topic Maps Model's merging rule for a-topics."

can be transformed into

  "there is a set A = {a_1, ..., a_n} of subjects"

. And 

  "The values of the components of the IS13250::a-sidp property
  (IS13250::a-sidp.t and IS13250::a- sidp.castingPairs{ }) must meet
  the constraints specified for them (see 4.2.2.2 and 4.2.2.3)."

would be

  "every a_i is a tuple

    <t, <(c_1,p_1), (c2,p_2), ...> >

  where t is ...."

> Sometimes we have to adapt to the complexity of the problems we
> face.  I suspect that the first time people outside the SGML
> movement saw DTDs, they, too, wondered why the solution to the
> problem of application-neutral information interchange should be so
> complicated.

Well, uhm, yes, thanks, now that you mention it... ;-]

> > This also may apply to TMM itself.
> 
> When we drafted the current version of the TMM, we decided to
> document reciprocal pointers from the perspective of both ends,
> instead of from only one of them.

You mean the document itself is not normalized? And modifications
would then propagated sporadically through the text? How do you ensure
completeness and consistency? Simply by going through the text?  I
admit that I do not fancy this kind of redundancy in formal texts.

And, is it clear to the implementer/reader that a second incarnation
of a constraint is such?

>           It could be argued that the new approach is
> unnecessarily repetitious, but it offers the advantage
> that implementers can clearly see, as they implement
> each part of the assertion model, everything relevant
> to the part that they're implementing.  The new
> approach is also clearer in that the consistency rules
> by which the conformance of implementations will be
> judged are all stated (and re-stated, as necessary)
> wherever they have effect.  We thought that, this way,
> implementers would be much less likely to misunderstand
> the text.

> any other form of *apparent* simplicity).  I think
> Einstein's famous remark applies here: "As simple as
> possible, and no simpler."  That was the mark we were
> trying to hit in N0393.

OK, that did not work out for me. My approach would have been to

 (a) have a orthonormalized document, as formal as possible (normative)
 (b) if that is perceived to harsh to the casual reader, then an
     'commentary text' explaining rationale/design would have to be added,
     (non-normative) and
 (c) a tutorial for the rest of us

Squeezing it into one forces to suboptimal compromises.

> > And: Is the structure of such a TMA document
> > predefined?
> 
> I think it makes sense to develop a DTD in the ISO
> context for this purpose.  We could even call it
> "TMCL", if we wanted to.  It should be a Topic Map
> interchange syntax -- one that is designed for the
> special purpose of specifying self-describing TMAs.
> (Just as XTM is primarily designed for the special
> purpose of specifying finding tools, such as indexes,
> etc.)

Are you saying that

    "one such document _defines_ a TMCL" or 
    "one such document is a definition of an ontology"

?

I am really looking forward to discuss this in more detail...

\rho