[topicmapmail] Use and abuse of occurrence

[Kal Ahmed]

On Tue, 2003-12-02 at 08:11, Gary Pupurs wrote:
> I've been following this conversation with interest (and the previous 
> Model A/Model T thread), as how to use and what facets are is one of 
> the things that have confused me the most in the past year since I've 
> discovered topic maps, and subsequently this list. Seeing facets in 
> the ISO models, but removed in XTM only made things worse.  More so 
> now that I'm beginning to think about implementing some of my own, 
> and discovered I needed facets or something like them.   But I'm 
> pleased to be able to follow much more of the discussion list than 
> when I first subscribed.  :)
> 
> Anyway, let's jump in...
> 
> On 01 Dec 2003 21:07:30 +0000, Kal Ahmed wrote:
> >Reductionism only gets you so far. It gets you to a graph and then
> >you
> >have to do the "Oh, but when you have that kind of node, you do 
> this"
> >dance. Its a hell of a lot easier to my mind to say "Occurrences
> >connect
> >topics to resources, associations connect topics to topics" than to
> >say
> >"look at all your connected nodes if its one of these then it means
> >this, if its one of those then it means the other". Sure it might
> >make
> >sense from an implementation point of view (though its not an
> >approach I
> >chose to take) - but its hellish difficult to explain.
> 
> Kal, I think you just defended Jan's basic argument, but left it a 
> step or two short.  I tend to favor Jan's view (more on that in a 
> bit); by you stating that properties can be handled in occurrances, 
> you're doing your own mental reductionism.  On this aspect, you and 
> Jan's counter-argument differ only in where you decide to stop the 
> conflation.
> 

Well, I wouldn't necessarily categorise my position as reductionist
seeing as I am arguing for the status quo ;-) My feeling is that the
balance is about right, so I am higly resistant to proposals to add
semantics that can be encoded using the existing mechanism of PSIs or to
conflate existing model properties and increase the gap between syntax
and model.

> Sure, adding Property or Facet is unnecessary, since it can be 
> represented with topic/associations, but this is also about clarity 
> and data exchange. If it adds clarity, makes it easier to understand 
> or adopt, it should be explored. Then we can look at implementation.
> 
> One thing I've noticed in the recent thread is that the debate is 
> happening now on _three_ different levels, often in the same message: 
> abstract model, XML serialization, and OOP implementation.  Those 
> have to be tackled separately, not together.
> 
> IMHO, however, a big point has been missed that is critical to topic 
> mapping's success.  Like it or not, the majority of web developers 
> and programmers will be introduced to topic maps via a graph drawing 
> and XTM snippet. Next they will delve further into the XTM syntax, 
> equating it with "topic maps".
> 
> Why?  Because concrete examples are easier to understand than 
> abstract standards descriptions in an ISO data model document.  Their 
> mental model will revolve around XTM, at least until they reach an 
> intermediate level where they're doing "under-the-covers" coding and 
> are referencing the ISO documents or building data storage code.
> 
> Now I base that somewhat unfounded assertion of a paragraph on my own 
> personal experience and observation of new technology adoption among 
> other programmers. HTML was easy to adopt because you could just 
> "View Source" on anything you found cool and try it out. 
> 

I agree with you there. I have always argued for a short mental distance
between the model and the existing syntaxes. Of course there is a
problem in that the topic maps model has two standard syntaxes to
represent, so it cannot be a straightforward mapping. Also I think that
there has been increasing clarity over the years as regards what topic
maps really are and the model tries to reflect some of that thinking
too. All that said I think that the jump from XTM to the topic maps
model is not too hard to make.

I would also mention here that in my experience most developers won't
ever read the model document once we as a community have developed a
common programming interface (see http://www.tmapi.org/).

> I see the current arguments for keeping property-like data in 
> occurrences as possibly leading down the same road as we strolled 
> with HTML.  Because nearly everything was a kludge in HTML until CSS2 
> layouts, it's tough to parse that legacy stuff.  But HTML took off 
> like wildfire because it was easy to understand.  Topic maps, 
> however, is still hard to understand, once past the "wow, this is 
> cool" stage and into the design/implementation stage.  And as long as 
> people are disagreeing about what an 'occurrance' is, interop will 
> suffer. (Certainly not to the degree HTML did.) 
> 
> With XSLT, we had a different story.  A flexible toolset that is 
> quite useful in many applications, but widely underused because of: 
> (1) an enormous, unintutive learning curve, and (2) lack of good and 
> affordable end-user GUI tools.
> 
> If, presumably, one of the goals is to catalyze widespread adoption 
> of topic maps, either XTM needs to make more sense out of the box to 
> a new developer wanting to add simple properties to a topic, or a 
> simplified description and full, free implementation of the Topic Map 
> Data Model in data/app form has to be more widely available as the 
> recommended learning gateway to topic maps. (The alternate syntaxes 
> of LTM, AsTMa, etc, may also have a role.) Something to shortcut 
> these perceived shortcomings of a somewhat generalized serialization 
> syntax.
> 
> >From my fairly well read but still somewhat new perspective, XTM 
> would make a lot more sense to new implementers if it had both 
> <property> and <metadata> subelements of <topic>.  (More descriptive 
> names might be <subjectProperty> and <topicMetadata>).  
> 
> There would be no need for someone new to fumble around with the 
> abstract idea of a topic to represent a topic's metadata, or 
> associations to topics which really are topics.  Nearly all 
> implementers or authors will want to add simple properties to their 
> maps; it must be exceedingly easy to do so.
> 

I sympathise with this point. I think that topic map meta data is vital,
but there is already a mechanism in reification to do this. As Bernard
has pointed out there is a problem if you extend this mechanism to the
creation of per-topic-metadata, but I don't think it is an
insurmountable problem.

As you are aware though, this is really a syntax issue not necessarily a
model issue, except that it increases distance between syntax and model.

> To tell the truth, one of the challenging aspects of learning topic 
> maps for me has been that they ARE so completely wide open and 
> flexible. While that is an inherent power of topic maps, it also 
> creates a bit of a mental roadblock when everything needs to be 
> abstracted out into associations. A more concrete syntactical 
> framework to hang learning on could help, while still leaving the 
> underlying logical model intact. (I think!)
> 

That was one of the issues I wanted to address by promoting topic map
design patterns. I agree with you that most developers work by the "View
Source" method. I would just like there to be more source to view and
more descriptions of why the source is the way it is. There is an
education issue here. To my mind this is actually far more important
than any amount of discussion of properties/occurrences/facets etc.
Maybe someone (or many people) would like to contribute some topic map
meta data patterns to www.topicmapcentral.com :)

Thanks for taking the time to write to the list. I'm sorry I didn't
address everything you raised point for point - but much of it I agree
with anyway.


Cheers,

Kal
-- 
Kal Ahmed, Techquila
Standards-based Information Management
e: kal@techquila.com
w: www.techquila.com
p: +44 7968 529531