[sc34wg3] occurrence - basename fuzzy border

[Murray Altheim]

Steve Pepper wrote:
> At 13:18 19.02.2003 +0000, Martin Bryan wrote:
> 
>> Since when is sorting relevant to occurrences?
> 
> 
> First of all, variants are not just about sorting (or display). They are
> about processing contexts in general. You may not have agreed with some
> of the decisions taken in the design of XTM, but please don't let this
> blind you to the fact that some useful generalizations *were* made and
> have since been adopted. Variants is one of them.

A "variant" is a useful generalization of topic base names. It also
complicates the markup language quite a lot. We felt it was worth it
in the end.

> Having said that, the answer to your question is: Sorting is relevant to
> occurrences *all the time*! Whenever you want to display a list of
> occurrences, the issue of sort order arises. Often there is no single
> sort order that is always correct; the choice will depend on the context.
> This could be handled by creating a topic for each resource and using
> the "sort name" of that topic determine the sort order, but in some
> situations this could be unnecessarily convoluted. Variant occurrences
> would allow you to solve the same problem with less machinery.
> 
> The more important issue is that of display. Surely you agree that the
> reasons for allowing multiple displayable versions of a name are
> equally relevant for occurrences? Think merely of a graphic that may
> exist in different notations, sizes, resolutions, colours, etc., each
> of which is relevant in different contexts. How is an application to
> choose between them?

This smacks so strongly of featuritis that I can't help but do the
common thing of accusing you of being an application vendor. Michel
had advocated (as I'm sure you remember) filling out <occurrence>
with an entire <baseName> substructure.

I think that while this may assist to some degree in display or
application-level processing, it is contrary to the paradigm in that
it fills out a topic map with style information, just as HTML ended
up with a ton of presentational content. What you're really talking
about is presentation, and a clever software system will contain
clever algorithms for sorting and display, caching, etc. It has
little or no place in an XTM document, IMO.

I think the most telling criticism is that, as you say, the sorting
and display information that would bloat out an XTM document might
very well be quite different in each different context, leading to
the occurrence <variant> being very heavyweight. On large topic maps
it seems problematic to have what are essentially presentational
characteristics potentially taking up so much space in the document,
when one could simply come up with an interesting GUI solution for
this (eg., using a sorted tree structure, using a graph, color-coding,
etc.) that took up no additional space whatsoever, and required no
additional recursive markup.

Murray

......................................................................
Murray Altheim                  <http://kmi.open.ac.uk/people/murray/>
Knowledge Media Institute
The Open University, Milton Keynes, Bucks, MK7 6AA, UK

     "In Las Vegas Mr Gates also demonstrated a prototype
      fridge magnet which can be programmed to receive traffic
      reports, sports results and advertisements from local
      restaurants using the same FM signal as the wristwatch."
                                  -- The Guardian, 10 Jan 2003.