[topicmapmail] Contextualized Topic Maps.

[Thomas Schwotzer]

Murray Altheim wrote:

> Thomas Schwotzer wrote:
> [...]
> 
>> What is knowledge? I'm afraid that would be out of scope
>> of this mailing list. Just some short statements about it:
> 
> [...]
> 
> Short? You're almost heading into my territory of long-windedness... :-)

It is an honour for me to able to compete with you at least
in this discipline.

> These are the only two places where the word "interpret" is included
> in your analysis. I would suggest that any discussion of knowledge
> include the context of interpretation. I.e., a common flow definition
> of information is "that which causes a change in its receiver". For
> information to be received by a person is one thing, but for it to
> become knowledge, it must be interpreted. Context is certainly
> important, but the most important context is that of the interpretation
> itself.

I don't think so. In knowledge management there is the
concept of tacit knowledge,. E.g. skill are tacit knowledge.
I wouldn't call it interpretation when I ride my bicycle.

You are right for explicit knowledge. Consuming an external
source is an act of interpretation.

>> I'm convinced that the current scope concept isn't sufficient
>> to cover all types of context. E.g. topics and associations cannot
>> be scoped. It would be useful, e.g. if a want to get a Topic Map
>> that only contains concepts regarding to dedicated place.
>> With scopes I cannot delete any topic. I can invalidate any
>> topic characteristic. But the topic itself remains in the
>> map. Scopes, in the current version, can be used to create
>> a view on a topic map but not to contextualize it which would
>> include removing topic map items. I think topic map fragmentation
>> can be technical means to contextualize topic maps.
> 
> 
> I think the idea of scoping topics is a bit of a non-sequitor, and
> is perhaps a mistaken understanding of the Topic Maps paradigm.
> In the real world as well as in Topic Maps, topics simply *exist*
	> (in TM, Topics are proxies for their subjects). I believe what
> you really want is the ability to provide a context in which those
> Topics play a role in an Association. And actually, Associations in
> Topic Maps can be scoped. 
Really? As far as I know, I can scope roles in an assocation
but not the association itself. Has it changed recently?

 > As to the rest of the analysis in the
> above paragraph, these are not deficiencies in the Topic Map
> paradigm, and are all the kinds of things that can be done (and are
> done) in Topic Map applications. 

Obviously, I did not make myself clear.
I was focussing more on the TM syntax than on the overall
paradigm when I complained about scopes.

Of course, I know that I can do whatever I want with a topic map
application. Actually, I already do. My only point was that
scopes are not sufficient to define any imaginable context types.
I guess, you'd agree.

 > Other statements are again mistaken
> on the basis of Topic scoping, such as the idea that
> 
>  > Scopes, in the current version, can be used to create
>  > a view on a topic map but not to contextualize it which would
>  > include removing topic map items.
> 
> To "contextualize" a Topic in relation (association) to a given
> subject, you'd scope those associations. You can then perform
> any operations, such as removal, that you like. 

Of course, you can add a topic for each context (type) to
a topic map and and associate any topic that fits to the context.
Is that what you mean? How would you handle overlapping context types?

Comming back to the pizza. Medical indications and mental states
might influence each other (if one feels sick and is also diabetic
he/she should avoid some food). Both are context types which
do influence each other. Such problems are usually handled with
logical terms. How would you solve it with associations?
Creating intersection of associated topics? Works well in this example.
But the relation between both context types must be explicitly known.

Of course, I can solve all these things with an application e.g.
by defining some TOLOG statements.

But what is required to make a Topic Map Engine a bit more context
aware? I don't have a solution. Are there classes of context types
which deserve additional concepts? Conceptually, I would never
propose to enhance the TM standard. It is fine as it is.
I think of defining some kinds of context types which can be
formalized by topics and associations. Topic Map Engines which
are aware of these context types can perform some additional
functions.

An example: One of my students (Holger Hammel) combined a
a Topic Map Engine with a geografic information system (GIS) in
it diploma thesis. In this system location is a context type.
The locations, coordinates, areas etc. are mostly defined by topics
and associations. Thus, for the Topic Map Engine it was an ordinary
Topic Map. But the LBS-TM Engine knows better and can interpret
some special types of topic and associations as location context.
This system can be asked for information of a given subject
(semantical context) at a location (spatial context). The result
is a topic map fragment which only contains information which
are related to the subject and relevant at a the location.

Actually, the fragment does not contain any location information
anymore. It was decontexualized.

Sorry, it was a lengthy reply, again.

Thomas
-- 
Thomas Schwotzer
University of Technology Berlin
Intelligent Networks and Management of Distributed Systems
http://ivs.tu-berlin.de/Schwotzer
fon: +49-30-314-79834 fax: +49-30-314-24573