Re: [topicmapmail] Re: [topicmaps-comment] RE: Ontologicalextravagance in the Topic Map Graph?

[Ivan Uemlianin <ivan@jurakm.com>]

Sam

Thank you for your comments:

Ontology ... "So, assuming that the number of concepts is the right 
metric to measure extravagance in an ontology, each proposal is 
extravagant in equal measure. (I'm not all that certain that 4 arcs and 
3 nodes are all that extravagant.)"

I suppose my language was a bit vague.  The two representations create 
different graphs (in the sense that they have different nodes and arcs), 
but they (have the expressive power to) represent exactly the same set 
of states of affairs (i.e. the set of all well-formed topic maps). 
TMPM4 uses a larger set of 'things' to describe the same set so, after 
Ockham or Quine, it is more extravagant.

I agree that 4 types of arc and 3 types of node is no Caligula's Hot 
Nights, but for example: ceteris paribus, having only one type of arc is 
surely better than having more than one.  If you allow four arcs, why 
not five or seven or ninety?  Why not have topic-basename arcs, or 
basename-variant arcs?  Instead of labelling arcs, why not have 
different arc types for every role type?  It can all be done with only 
one type of arc so why have more?

I'm sure there are good reasons for all these arc types node types and 
ill-defined non-graph appendages.  Please would someone point them out 
to me?

 > I'm
 > not sure if a statement like "this type of node makes this type of
 > function easier to implement" is appropriate for ontology evaluation.
 > Perhaps ontologies have their own inner design integrity ("smell", in
 > extreme programming terms), regardless of what is done with them?

I agree.  As far as I can see the two representations can represent 
exactly the same set of topic maps, and I haven't considered 
implementation issues at all.  Presumably a more formally coherent 
representation should be easier to implement, but maybe not.  Certainly 
the behaviour of a more formally coherent representation should be 
easier to predict.

On RDF:
I'd naively assumed that the TMPM4 team had RDF in mind when they were 
designing the graph.  I certainly had it in mind when I was reading it.

More generally, RDF just seems too useful to ignore.

Ivan

Ivan Uemlianin, PhD

Head of Topic Map Development
Jura Technology Limited

6 Tai Seion
Llanddeiniolen
Caernarfon
Gwynedd LL55 3AF
Wales, UK

Head Office:
35 Norroy Road
Putney
London SW15 1PQ
UK