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

[Nikita Ogievetsky <nogievet@cogx.com>]

Ivan,

I think authors of TMPM4 were driven by exactly this idea to minimize number
of basic
concepts which are nodes and arcs. And 3/4 is where they got to.
If you believe that you have any better ideas, everybody would be glad to
here them.

Here is a quick summary of TMPM4 as I see it:
a-node and t-node are basic nodes.
Assoc-Topic is the basic arc, it is the only labeled, or "triangle" arc.
Assoc-Template arc also connects associations and topics, but is really
different as it hides a singularity
of instanceOf and subClass relationships inside.
s-nodes provide namespace mechanism which looks pretty important to me.
Assoc-Scope and Scope-Topic are corresponding primitive arcs.

So we have 3 types of objects: 3 nodes, 3 arcs and 1 triangle arc.

BTW I missed which 2 representations are you talking about.

RDF is not ignored, there are several researches on how to express
Topic Maps in RDF via TMPM4:
http://www.semanticweb.org/SWWS/program/full/paper53.pdf
http://www.cogx.com/rdfglasses.html

--Nikita Ogievetsky
Cogitech, Inc. http://www.cogx.com

----- Original Message -----
From: "Ivan Uemlianin" <ivan@jurakm.com>
Cc: <topicmaps-comment@lists.oasis-open.org>; "xtm-tech"
<topicmapmail@infoloom.com>
Sent: Friday, November 23, 2001 2:33 AM
Subject: Re: [topicmapmail] Re: [topicmaps-comment] RE: Ontological
extravagance in the Topic Map Graph?


> 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
>
>
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>
>