[topicmapmail] Proposal: Extending the Role of Occurrence Elements

[Murray Altheim]

rmorikaw@gmu.edu wrote:
> Good points.  I looked at using associations such as "suspected connection", 
> etc... similar to your "is or isNotValidated", but the problem I was running 
> into was that if two analysts, sharing the same topic map, disagree on 
> plausible associations or their relevancies, you would have difficulty 
> representing the opposing views.  You could add additional associations for 
> each view such that each view is attributed to their analyst - i.e. associations
> such as "suspected_connection_analystA", etc.  Doing this might lead to a high 
> order of complexity as well as resource limitations however.

I'd use the Topic Map scope feature to provide the context for each assertion,
adding in Topics "analystA" and "analystB" rather than creating a new
association type. You're just creating more associations, and scoping them
and typing them appropriately.

I don't think modeling this in TM is going to be any more or less complex
than the information you're modeling, which is fairly complex. The benefit
of modeling isn't really to reduce complexity but to fit it into well-known
categories and structures.

> In addition, say you were to apply Bayesian theory to your 911 issue in order
> to determine most probable causes for each event.  There are two ways you can
> do this.  First, you can stay within the current topic map paradigm and, by 
> properly scoping topics and by making some "would-be" occurrences (e.g. a 
> meeting of suspects)  into topics themselves, you could perform a search and
> analyze your resulting  temporal sequence (which might be complex when dealing
> with time intervals vice time point - i.e. valid time or transaction time) and
> assign probabilities/weights. This would probably work, but the complexity might
> be high.

Again, the complexity would likely be no higher than the complexity of the data
you're modeling. Most of this kind of thing will happen a layer above the TM layer,
at an application level where you harvest the TM information to produce the
Bayesian net.

> Second, you could extract relevant occurrences, annotate these occurrences with 
> one or more types (e.g. type1:intelReport, type2:nefariousObservedActivityDomestic,
> etc. - not currently allowed in XTM), add time and associated relevancies (also
> not allowed in XTM).  Complexity is less as far as the shared topic map is 
> concerned, of course the price you pay is that you now need to support a separate
> analysis space.

In the past few years I've seen a lot of people think they needed to extend the
Topic Map paradigm to do something. Looking back, almost always it was usually
a matter of using Topic Maps appropriately and building on top of them the features
needed, not extending them. So while temporal modeling isn't *in* TM, it could
be build *on* TM.

> Can you expound a bit on your idea of using an enumerated list of relevancy and
> scalar values for occurrence elements?

Sorry, but my meter just ran out. I've unfortunately got my own tight
deadlines this week. In short though, in my own work I use PSIs to
declare datatypes for occurrence contents. The trick is to figure out
when you need to create a topic and when an occurrence can be added to
an existing topic without doing violence to the model. I'm trying to
avoid overloading or abusing the XTM markup as much as possible.

Murray

...........................................................................
Murray Altheim                         http://kmi.open.ac.uk/people/murray/
Knowledge Media Institute
The Open University, Milton Keynes, Bucks, MK7 6AA, UK                    .

    "The parties themselves, working with the Arab nations, have to find a
    way to co-operate to fight terror, without putting American forces in
    an area where they will become targets."
                              -- White House Press Secretary Ari Fleischer.
                  http://news.bbc.co.uk/1/hi/world/middle_east/2989154.stm