[topicmapmail] k42 and superclass-subclass and class-instance relationships

[Thomas B. Passin]

[Magdalena Litwin]
Currently I'm trying to design the database of enzymes based on topic maps.
I'm using the Empolis k42 application. I have a problem with
superclass-subclass and class-instance relations.

Let's say that I want to model such an association: each enzyme has a number
called EC number i.e. EC number of an alcohol dehydrogenaze is 1.1.1.1.  I
have created topic "number", topic "EC" and "1.1.1.1". I thing they should
be connected by superclass-subclass relationship which is tranzitive - it
means that I can claim that "1.1.1.1" is an instance of "number". I have
created also a topic "alcohol dehydrogenaze". Then, I have defined an
association template:
    - "enzyme" has an "number",
    - "number" is associated with an "enzyme".
But I cannot to asign any concrete value to the number.

I have tried to implement the same hierarchy using a class-instance
relationship. It works but only if I marked that "1.1.1.1" is an instance
not only a topic "EC" but also a topic "number".
So how should I model such relationships in k42? I thought it is enough to
say that "1.1.1.1" is an instance of "EC" and "EC" is an instance of
"number" and the relationship between topics: "1.1.1.1" and "number" is
obvious.

[Tom P]

How you model something will depend in part on what you want to do with it.
My immediate inclination is to make the value of the EC number to be an
occurrence of an enzyme.  The type of the occurrence would be a topic
labeled, probably, "EC Number".

To make the EC number "1.1.1.1" to be a topic would only be useful if you
had a distinct idea of that particular EC number as a subject in its own
right.  For example, if you wanted to explain that it had some special
meaning, then it would make sense to create a topic for it.  You would
probably want to make that topic to be an instance of a topic type "EC
Number".  You would have to connect "1.1.1.1" to your enzyme topic with an
association, as you started out doing.

If this is not the case, and there is nothing special to say about that
coordination number, make it an occurrence of the enzyme topic.  You might
arrange the types (I mean subclasses) like this (I am just making this up
for illustration) -

Thing
   Molecule
      Enzyme
   Descriptive Property
      EC number

Then "alcohol dehydrogenaze" would be an instance of Enzyme, and "1.1.1.1"
would be the value of an occurrence whose type was "EC Number".

Unless you see the designation "1.1.1.1" as some kind of a number, which I
think is unlikely, I would not make "EC Number" to be a subclass of number.
If you do you will confuse everyone else, because they will think you mean
some kind of ordinary number.

If you do find a need to make "1.1.1.1" into a topic of its own, your type
hierarchy might look like this -

Thing
   Molecule
      Enzyme
   Designation
      EC number

"1.1.1.1" would be an instance of "EC Number", which would be a subclass of
"Designation".

The message is to work out how you think about these things, and what you
want to say about them.  After that you can decide how to model them.  Of
course, this is usually an iterative process.

Cheers,

Tom P