[topicmapmail] tolog: specifying the TM

[Murray Altheim]

Quoting Richard Light <richard at light.demon.co.uk>:

> In message <20060629104917.c1njyb6vbu8sc4s4 at www.altheim.com>, Murray
> Altheim <murray06 at altheim.com> writes
>>
>> So "which Topic Map?" really became more of a question of "which
>> Topic Maps?", [...] __which__ Topic Map can't have a standardized
>> answer, it would be application-dependent.
>
> I take your point.  However, I would have thought that it would make
> sense to be able to specify a "starting-point" Topic Map, analogous to
> HyTime's Hub Document: a "Hub TM".  Otherwise, how can you make sense
> of the results of queries, when _what_ you are querying is not
> well-defined?

Yes, but specification of the "hub TM" would be application-dependent
as well. I didn't say "identification" because there simply isn't a
standardized way to identify a Topic Map document (and to be clear,
I am not suggesting there should be).

> In XTM, you have explicit inclusion (mergeMap), and implicit inclusion,
> as you describe above.  If I were setting up a framework to support
> Topic Map querying, I would expect to obey any mergeMap instructions in
> my Hub TM when preparing my TMDM for querying, but I wouldn't expect to
> have to expand the scope of my TMDM to include TM constructs which are
> simply referenced therein.  The fact that the _references_ are there
> means that they can be queried: you don't need to referred-to objects
> as well.

If the hub document isn't permitted to do whatever recursive inclusions
as are necessary and implied by whatever it and any inclusions demand,
one is possibly left with an incomplete Topic Map (or one simply wouldn't
know if it were complete or not). Depending on the application and the
type of query, this might be a desired situation, even for the same
Topic Map (e.g., one might want to query the environs of only a very
specific document within a set of interlinked documents, or permit the
inclusion of any necessary documents as either utility, background Topics
and Associations, properties, metadata, ontological add-ons, whatever).

> If you don't accept this argument, and assert that all TMs whose
> members are referenced should be included in the TMDM, it rather begs
> the question of what mergeMap is there to do.  Explicitly include
> material which is totally unrelated to the Hub TM?

It's not that I don't accept the argument, but MergeMap is just
the mechanism. The actual functioning of that mechanism, i.e.,
the specific situations in which one wants that mechanism to
operate, and even *how* it operates, will very likely be both
application- and context-specific. And I'd certainly argue that
any MergeMap that is in a typical Topic Map document could
hardly be considered "unrelated" to the Hub TM, it's just that
from a user perspective one can't necessarily know how or why
it is related. It may be a utility TM used to provide application-
specific functionality (and therefore outside of the scope of
the query) or a completely necessary but opaque addition to the
overall Topic Map.

I just don't think there is a general case answer to this
question, hence no possibility of a suitable standardization.

Murray

...........................................................................
Murray Altheim <murray06 at altheim.com>                              ===  = =
http://www.altheim.com/murray/                                     = =  ===
SGML Grease Monkey, Banjo Player, Wantanabe Zen Monk               = =  = =

       In the evening
       The rice leaves in the garden
       Rustle in the autumn wind
       That blows through my reed hut.  -- Minamoto no Tsunenobu