[topicmapmail] Announcement of XML Schema for ISO13250Topic Maps

[Patrick Durusau]

David,

David RR Webber wrote:

> Message text written by Patrick Durusau
> >***
> When was the last time you had to go "looking under the hood" of a Word
> document to determine the source of an error?
>
> The creator(s) of topic maps would need that level of access to debug an
> interface but one assumes they would have more sophisticated tools for that
> process.
>
> >>>>>>>>>>>
>
> Boy am I glad you raised this!  I really think we should rely on M$ to
> build
> the single dominant product in the TM space - with 90% of the market.
> This really solves all issues of interoperability on the spot.
> Of course if we are going to have lots of vendors instead - then
> implementation issues will arise.
> <<<
>

I used Word as an example of an interface that users normally don't look under
to diagnose errors. It was not meant to suggest or support an "M$" topic map
application of similar dominance. That will happen only if topicmap software
vendors try to impress their consulting clients with a lot of unnecessary
angle-bang syntax to justify their fees/products. The construction of a
topicmap and its underlying ontology are non-trivial tasks but data entry is
not something that should be dressed up as knowledge engineering. M$ dominates
not through high quality software but because its software can be used by the
average user to produce results. My use of the Word example was merely to
suggest that topicmap vendors should offer products that are useful without a
lot of behind the screen work (or access) by the average user.


>
> >
> The problem with "angle-bang" interfaces is that they may actually
> slow the adoption of XML and related solutions due to the learning curve
> for
> the average user. If the angle-bang syntax is not relevant to their task,
> what
> advantage is there in asking users to learn it? Users range from the data
> entry
> clerks and subject matter specialists to the topic map creators. Since they
> have differing needs in terms of access to the underlying markup, why
> should
> they all have the same interface?
> <
> >>>>>>>>>>>>>>>>>>
>
> Let's not be too tough on users.  Alot of them are much smarter than given
> credit - and they appreciate being able to review underlying semantics
> when it is important to their process.   See our HR-XML implementation
> to see how the angle bracket tags context is exposed to the end user.
> (http://www.goxml.com  and Test Drive link).
>

I think we are talking about two different views of "users" and hence some of
the divergence in our comments. I see users as occupying various levels of
skills and interests, ranging from data entry clerks and temp staff to content
specialists and topicmap designers. The question in my situation is what
interface will make the largest number of users the most productive. Since the
users have different tasks, I see no reason for them to not have different
views of the underlying process. Some would see only a form with text fields
for data entry. Others would see only drop down menus of topics and
associations. Still others would see all of the forgoing but have the ability,
again controlled by the interface, to add new associations or topics. At the
very top of the pyramid would be the adminstrator who could set the rights to
all of the foregoing.

Contrast that will the assumption of user equality (demonstrably false BTW)
that seems to underlie the notion that users generally should be allowed to
access the underlying semantics in the building of a topic map. Given a fairly
controlled group of highly skilled users it might produce acceptable results in
a production environment. With less than an controlled group of such users, the
results probably would not be acceptable in most working situations.

Assuming your demo was working properly (BTW, I liked the search interface) it
simply exposed the XML markup of the entry matching the search query. I am not
sure why you would find that helpful. Since your interface allows the choice of
the portion of the entry to be searched in a menu, I don't need knowledge of
the markup presented in angle-bang syntax to decide where to search.


>
> Notice if they can see such detail they can resolve semantic disconnects.
>
> I also see that IT staff need at least a fighting chance of debugging the
> 'MS Word' level of the world.  If you import a RTF into Word and it does
> something really ugly - would you like to be able to fix that?
>

Having worked as "IT staff" in the past, I see no reason why properly trained
IT staff could not "debug" problems with a topic map. But that would require
more training and a different interface (IMHO) than the average users.
Constrast the user not being able to login to the Novell Network using a
standard client and diagnosis of the problem using NetWare Admin and a host of
other utilities. All the user sees is a failed login, while the network admin
can use better tools to diagnosis and fix (hopefully!) the problem. They are
both "using" the same network, but with radically different views of the
underlying process.


Patrick

--
Patrick Durusau
Director of Research and Development
Society of Biblical Literature
pdurusau@emory.edu