[topicmapmail] Subject Identifiers metadata

[Dan Corwin]

Hi Kal -

> Can you give an example of the need to reify the topic?

Sure.  I can imagine whole classes of topic maps that try to describe
good or bad modeling techniques - just as this thread does on a "best
practices" issue.  And which therefore would need to reify specific
topics as examples, then add characteristics saying that they were
good or bad illustrations of technique, and explaining why.  Any
"basic training manual" topic map on the Topic Map paradigm might
need similar examples of topics.

Tom suggests PSIs are an answer; for the above they might work.  But
I think "versioning" or DC-type metadata would be useful for topics
in any ontology, or in any dynamic TM being built collaboratively by
a group (such as in a wiki).  Characteristics assigned by reviewers,
Q/A staff, etc. might also be attached, not to model the subject of
the topic, but how well it was built.  And here, PSIs seem unlikely.

Nearer to home, suppose I want a servlet to map any English grammar
form into a topic modeling its referent.  Textual ambiguities cause
multiple topics to emerge as competing meanings.  So I would like
to reify each of these "meaning" topics in XTM output, then tag on
metadata to model its source, plausibility, competitors, etc.

Philosophically, not being able to cite topics as normal subjects
is very much like blocking all public discussion of an idea or any
other type of symbol (as distinct from whatever it might signify).

Unless such discussion becomes possible and reliable, Topic Map
mutation tools that need to add topic metadata all get crippled,
and limited in how introspective they can become.

In a modeling paradigm like TMs, where sophisticated tools can
help out, the alternative seems to be a big ontological glitch.
I hope it gets removed soon from TM engines and future specs.

Meanwhile, philosophically, it also turns "anything whatsoever"
claims about topics' potential subjects into overblown marketing
hype, and that bugs me as much as the related practical barriers.

> The note [in TMDM specs] says that you cannot reify a topic. You
> can, however, reify any characteristic of the topic.

I can figure out workarounds to let me (improperly) add topic metadata
as characteristics to any topic - typically the one I'd reify.  But
such techniques violate TM premises, and I doubt they are necessary.

Characteristics normally have no conflicting "identity" issues in
their own right.  Topics do; and so do your subject identifiers.
And that is precisely why I linked up these issues in my reply.

In both cases, the identity of some *symbol*, versus that of whatever it
symbolizes, is the true origin of the conflict.  The TMDM note appears
to deliberately recognize only the second of these options.  And in its
definition of <topicRef>, so does XTM 1.0.  Why block the first option?

My concern here is really the same one several folks on this list have
raised about ambiguity within RDF symbols: do they identify a resource
(like a topic), or something else which that resource symbolizes?

TM's have *externally* solved such conflicts (with web-wide gloating)
by adjusting the syntax of XTM to handle both cases for a URI:

   <resourceRef>
   <subjectIndicatorRef>

I would hope TMDM can now spec analogous distinctions between the two
*internal* cases.  Implemention-wise, I'd guess it really takes only a
new boolean feature (or bit) to discrimiate saved "reifier" pointers,
plus some additional syntax at the XTM level to let it be persisted.

But I may here be second-guessing more authoritative answers from the
recent Amsterdam meetings, which is exactly why I started by asking...

> Q1: Were these reification limits in TDMD in fact recently discussed?
>
> Q2: Either way, does a consensus now exist on their resolution?
>
> Q3: TMDM specs aside, could I in practice reify such things in XTM
>     1.0, then safely expect all popular TM engines to handle it?

Still hoping for answers...
Dan Corwin