[topicmapmail] Announcement of XML Schema for ISO 13250Topic Maps

Patrick Durusau pdurusau@emory.edu
Sun, 24 Dec 2000 15:58:42 -0500


--------------03F00F9D162E7FBBFCE72197
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

David,

Reply *** below:

David RR Webber wrote:

> Message text written by Patrick Durusau
> >I am just not certain that I would choose ISO
> 13250 over XTM simply because I had a difficult interface for users. The
> more
> obvious solution, to me at any rate, would be to create a better user
> interface,
> whichever standard, ISO 13250 or XTM that was chosen for the task at hand.<
>
> >>>>>>>>>>>>>
>
> This is the argument that the W3C uses to sell Schema too.  Users will
> never have to look at the underlying syntax.
>
> Yeah - right - until they get an error message and the whole thing
> stops processing and then they have no way of looking under the
> hood to determine why.
>

***
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. 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?

>
> Been there done that.
>
> I'm with Martin - keep it simple for the humans to do in the first place.
>

***
I thought my suggestion was to keep it "simple for the humans" by using an
interface that allows them to construct a topic map without having to learn the
proper syntax. That allows the users to "import" their specialized subject
matter knowledge without learning the required syntax. How is that making it
more complicated?

On your later reply to Michel's post pointing out the need for various display
names you note:


> That's a great point - and actually re-inforces Martins point that
> we can't be limited to a single set of rigid tagsets.
>

It is important to distinguish (as you do with reference to bizcodes) between
what is displayed to the user and the underlying encoding. The existence of a
single underlying tagset in XTM has no impact on what is displayed to the user.
What is displayed to the user is the choice of the interface designer. (And the
existence of display names in the topic map.)

As for human verification, I suspect experience will show that even relatively
simply topic maps will quickly grow beyond human verification, at least in the
sense of verifying the syntax of the map. Human subject matter specialists will
be called upon to judge the accuracy of the content of the topic map but that
is an entirely different issue. Properly written topic map software should
generate a valid topic map and not one that requires manual correction by the
user.

My community of users (biblical scholars) are an example of a group that would
profit from the use of topic maps, but I doubt very seriously that I can entice
very many of them to use angle-bang interfaces. On the other hand, if
interfaces are constructed that allow them to select topics, associations
between topics, occurrences, etc., and highlight text with automatic (and
hidden) generation of XLinks/XPointers, topic maps may become a standard part
of their work. All I am suggesting is that interfaces should be used to promote
the usage of XML in general and topic maps in particular, without annoying
users with information that is both unwanted and unnecessary to the task at
hand.


Patrick

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


--------------03F00F9D162E7FBBFCE72197
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
David,

Reply *** below:

David RR Webber wrote:

Message text written by Patrick Durusau
>I am just not certain that I would choose ISO
13250 over XTM simply because I had a difficult interface for users. The
more
obvious solution, to me at any rate, would be to create a better user
interface,
whichever standard, ISO 13250 or XTM that was chosen for the task at hand.<

>>>>>>>>>>>>>

This is the argument that the W3C uses to sell Schema too.  Users will
never have to look at the underlying syntax.

Yeah - right - until they get an error message and the whole thing
stops processing and then they have no way of looking under the
hood to determine why.
 

***
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. 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?

 
Been there done that.

I'm with Martin - keep it simple for the humans to do in the first place.
 

***
I thought my suggestion was to keep it "simple for the humans" by using an interface that allows them to construct a topic map without having to learn the proper syntax. That allows the users to "import" their specialized subject matter knowledge without learning the required syntax. How is that making it more complicated?

On your later reply to Michel's post pointing out the need for various display names you note:
 

That's a great point - and actually re-inforces Martins point that
we can't be limited to a single set of rigid tagsets.


It is important to distinguish (as you do with reference to bizcodes) between what is displayed to the user and the underlying encoding. The existence of a single underlying tagset in XTM has no impact on what is displayed to the user. What is displayed to the user is the choice of the interface designer. (And the existence of display names in the topic map.)

As for human verification, I suspect experience will show that even relatively simply topic maps will quickly grow beyond human verification, at least in the sense of verifying the syntax of the map. Human subject matter specialists will be called upon to judge the accuracy of the content of the topic map but that is an entirely different issue. Properly written topic map software should generate a valid topic map and not one that requires manual correction by the user.

My community of users (biblical scholars) are an example of a group that would profit from the use of topic maps, but I doubt very seriously that I can entice very many of them to use angle-bang interfaces. On the other hand, if interfaces are constructed that allow them to select topics, associations between topics, occurrences, etc., and highlight text with automatic (and hidden) generation of XLinks/XPointers, topic maps may become a standard part of their work. All I am suggesting is that interfaces should be used to promote the usage of XML in general and topic maps in particular, without annoying users with information that is both unwanted and unnecessary to the task at hand.
 

Patrick

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