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

[Patrick Durusau]

Martin,

Thanks for the explanation! Comments below:

Martin Bryan wrote:

> Patrick
>
> > The point is that I would prefer that you state what objections you have
> to XTM
> > without name calling or assuming that "efficient enough for the long-term
> > management of semantics" is a meaningful statement without more
> information.
>
> Good question.  See below for my detailed explanation.
>

<snip>

>
> The problem I have, as I stated volubally in Swindon before giving up trying
> to get any of the developers to listen, is the long-term management of
> "typing" of occurrences. When people start to create topic maps they will
> almost certainly create a single type of occurrence, and will not assign
> them roles. As time goes on and they try to relate their maps to other
> peoples maps, they will begin to understand how vital roles are to
> differentiating the reasons why occurrences were assigned to topic maps.
> When we come to trying to use multiple maps as a single whole we will find
> that there will increasingly be a need to restrict our queries based on the
> reasons why specific occurrences were assigned to particular topics. (You
> have only got to look at the web to see how vital the "reason for
> publishing" data on any subject is.)
>

No disagreement on the need to "type" occurrences. But what you describe is a
management (or implementation?) problem with users, not the syntax of XTM.
Correct? Unless you are suggesting that XTM or other XML based topic map
solution should require users to "type" occurrences. There is nothing in the XTM
syntax that forces users to create a single type of occurrence, that is simply
poor planning on their part, something that I am not sure we can address within
the XTM effort.

If XTM prevented users from typing occurrences, then I think you objection would
raise a serious question about its viability. But I think, subject to
correction, that you are suggesting users will not type occurrences, which is an
entirely different question.


>
> The same goes with facets. At first they seem totally a waste of time, but
> when it comes to long-term research you will see how vital they are. You
> will need to look carefully at any occurrences associated with the Topic Map
> topic during September 1999 and January 2000 to understand why some of my
> utterences now differ from some of those stated in 1998. Where do you get
> the information needed to differentiate between occurrences made in these
> two periods within a topic map? How will you be able to differentiate the
> occurrences already recorded about my statements on the use of ISO 13250
> (SGML) Topic Maps from those that are made about XML Schema for ISO 13250
> Topic Maps? This is one of the weaknesses of XTM. Without a formal facet
> handling mechanism you cannot make such distinctions and still be able to
> find all occurrences of items relating to Topic Maps.
>

As Murray noted in an earlier post on this thread, facets can certainly be
implemented using XTM syntax. On your example, would not the instanceOf element
be sufficient to record occurrences of ISO 13250, instanceOf = SGML versus
instanceOf = XML Schema?


>
> Now lets go back to the real problem. Try writing an XML Path based query
> into an XTM representation of a topic map, and then try writing one based on
> an XML Schema that uses role names as element names.
> For my topic maps I have something like:
>
> ?Standard/Names/Acronym["RDF"]?GET?FormsBasisFor
>
> For XTM I get something along the lines
>
> ?Topic/TopicNames/BaseName["RDF"]?GET?Occurs/Type["FormsBasisFor"]
>
> OK not much apparent difference for such a simple query, and of course I
> will be told that "tools will hide all this crap from users" again and
> again.

No, sorry to disappoint. See comments for next section.


> I don't care about what end-users see - I do care about how easy it
> is for system administrators to work out what the problem really is when an
> irate managing director is yelling down the phone asking why the answers the
> stupid topic map engine returned were not the ones he expected to see, and
> that the administrators job is on the line if the correct answers aren't in
> the board room in 2 minutes. In such real life situations you need to
> maximize the amount of real information available to the administrator. This
> is where typed elements will come into their own - in those situations where
> quick decisions are needed.
>

I take it that the issue is not the interface or lack thereof but a notion that
administrators should be able to troubleshoot topicmap results by visual
inspection? Perhaps workable with the type of semantics you have proposed but
only with very limited topicmaps. Consider the case of biblical studies. I have
almost 75 pages (single spaced) of subject classifications based upon a European
classification effort, that does not include any associations between topics,
scope, etc. And that is at a fairly high level that is used by librarians, not
subject matter specialists. I doubt very seriously that any administrator, using
your semantics or not, could manually trouble shoot the results of a query to a
topic map based on that information. Even more so once the contributions of
subject matter specialists begins to create even more finely grained topics.

I am curious what you see as the administrator's role if the "irate managing
director" gets results from an SQL query that are "not the ones he expected to
see..." It could be that the director's expectations are simply incorrect and
not a problem with the database or SQL query. If you suspect that I would
privilege a properly designed application (database or topicmap) over
seat-of-the-pants judgment, you would be correct. (That is probably off topic
for this discussion but it may be influencing my reliance on automated
processing versus visual inspection so I wanted to note it.)

The more complex a topicmap becomes the more difficult it will be for
administrators to trouble shoot problems by manual examination of the underlying
topic map. I suspect specialized tools will be developed to implement, test and
maintain topicmaps, particularly those that have any significant size. Not quite
the Indiana Jones type image we might like to project but certainly the reality
of working with complex information systems.

Happy New Year to everyone!

Patrick

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