[topicmapmail] Topic map design guidelines?

[Jan Algermissen]

schoenfeld.i@atlas.de wrote:
> 
> Hi all,
> 
> does anyone knows about a kind of style guide, guidelines or best practices of how to design good topic maps? 

Ingo--

I suggest that you look at some of the extensive material on data modeling,
the general principles apply to data modeling with topic maps also.

Some stuff to consider:

- what are your classes? (although not a structural part of
  the Topic Maps paradigm, classes are still a major design
  element)

- don't mix classes and roles. 'Person' is a class, while 'Teacher'
  is a role.
  (see: http://www.infoloom.com/pipermail/topicmapmail/2002q1/003566.html )

- define the controlled vocabulary of your domain, avoid ambigous
  names

- what are properties, what are relationships? Relationships
  map directly to associations and participating roles provide
  a fine secondary classification of your instances (e.g. "what
  persons are teachers?" ==> find all players of role teacher)

  Properties of your instances (e.g. Age, Height, Address,...)
  can only be expressed by tweaking the semantics of <occurrence>
  a bit (in the absence of a dedicated property element in XTM):

  <topic>
    <occurrence>
      <instanceOf>
        <subjectIndicatorRef xlink:href="http://.../Age" />
      </instanceOf>
      <resourceData>12</resourceData>
    </occurrence>
  </topic>

  This arguably does not leave much room for data typing the '12',
  but there is currently no other way.

  Hmm...., you could combine your XTM with RDF, given the TM engine you
  use supports this. E.g. along the following lines:

  In your XTM put:
  <topic>
    <subjectIdentity>
      <subjectIndicatorRef xlink:href="http://people.org/mary" />
    </subjectIdentity>
    <!-- ... -->
  </topic>

  In your RDF put:

  <rdf:description about="http://people.org/mary">
     <foo:age>12</foo:age>
  </rdf:description>

  Via RDF schema the semantics and data type of foo:age can be defined.


- You should also (from my experience) restrict yourself to

  - using a given role only once in an association (no multiple
    role players)

  - using a given role only in associations of a single type (the
    combination of the roles is essentially what constitutes the
    type of relationship, so they should not be mixed across
    different types). This also enables you to select associations
    soly by role: "find all assocications where X plays superclass"
    as opposed to "find all assocications of type superclass-subclass
    where X plays superclass".

Anyhow, just some guidelines I follow. Hope they help a bit.


Jan

  
    

Jan Algermissen                           http://www.topicmapping.com
Consultant & Programmer	                  http://www.gooseworks.org