[topicmapmail] Not just Temporality in Topic Maps, but a whole approach

[Simon Grant]

Useful comments, thanks! ...

At 13:18 2006-06-08, Kal Ahmed wrote:
>My approach of late has been to shield users from topic maps almost
>completely. There is really no reason at all why an application user needs
>to know about the underlying model for representation.

Agreed - the implementation of a useful system can potentially be at 
any level. My interest is based on a hypothesis - evidence either way 
would be welcomed - that implementing in a language which is 
relatively close to the user's language, and where the ontology is 
represented in a way that is relatively close to the way the user 
thinks about it, will tend to be easier, more cost-effective, and 
generally therefore better quality in the end (given universal 
constraints on time and money).

That is what interests me about Topic Maps. Immediately I read the 
comparison of TM and RDF I got the impression that TM representations 
could easily be closer to the way the user thinks of the domain than 
(say) RDF. Now, I don't have a metric for "closer" here, just an 
intuition, which no doubt many others share.

To me, the whole issue (nearly wrote "topic" - oops!) of user 
education is fascinating. No doubt there are trade-offs: how much 
effort does one offer to put into training or educating the 
user/client, and how much into building user-specific higher-level 
abstractions, absorbing the work of relating that higher-level 
abstraction to a TM representation? I would guess it depends on how 
functional or dysfunctional the client's "native" mental model is: 
e.g. does it have inconsistencies or logical holes?

It seems not unlike more general systems analysis issues. There is a 
great deal to be said for having the client understand whatever 
models are part of the analysis process - much more than the detailed 
design. Again, the impression I get is that it can be quick to get 
together a TM representation of what the client thinks they think, 
and to use it Socratically for their education. I wonder if people do that?

Anyway, just to reiterate my interest: using TM to represent 
knowledge as closely as reasonable to the way it is "in the wild".

Simon

>Shielding the user can be done by dumbing-down the model or by creating
>higher-level (often domain-specific) abstractions on top of it. For example,
>many users have a hard time getting to grips with "anything can be a type"
>and "associations can have any number of roles" amongst other features of
>topic maps, so defining an application that has a fixed set of types and
>maybe that restricts users to binary associations only can help. On the
>other hand there are some things that really require the full power of the
>topic maps model to be represented and that is where using patterns and
>higher level abstractions can help - e.g. abstracting the creation of
>hierarchies or thesauri; or creating domain-specific abstractions.
>
>That said, to do this effectively, a developer really has to have a handle
>on the underlying model. Sure, you might be able to wing it, but if you
>really know what topic maps are all about, your end-user will get a better
>application. The topic maps model is your tool and you will create better
>apps if you have a solid understanding of the tools you use.
>
>I can't answer for all the people on this list, but I suspect that a large
>proportion of them are similar to me - both a developer and a user. So both
>of the above apply - I want to be shielded from complexity by apps that dumb
>down or abstract away from the topic maps model, but I also want the full
>power of the model so that I can create those apps in the first place.
>
>Cheers
>
>Kal