The Schema Tool

The Schema Tool has been discussed so far only in the article Diederich, Fortuner & Milton, 2000. A uniform representation for the plan of organization of nematodes of the order Tylenchida, Nematology 2(8): 805-822. This article states that:

In the future Genisys database, each concept will be represented in a text file using a specified syntax.  Generally speaking, this will not be seen by any user.  A designer will normally refer to the syntax only to see what can be represented by the concept.  Both user and designer will normally interact with the schema via a tool for building and displaying the schema.  This schema tool will also provide some automatic operations such as generating standard synonyms for a particular concept.  Finally, each concept will be used within the database itself, often as the field name for the structure in question.

The Schema Tool will implement the various name extensions discussed in the present page.

1. Perspectives

A perspective consists of three components: the term  'Perspective', its type, and the name of a structure. 

The textual representation has the following syntax:
        'Perspective - <type>' <structure-name>
where  <type> is one of  {Face view = Anterior view, Lateral view, Cross-section, Posterior view} and <structure-name> is the name of the principal view, i.e., the structure.  

A schema tool should automatically generate a name and common synonyms.  Synonyms are indicated after a sign '=' and they have the following form:
<structure-name> <type> =  <type> of the <structure-name>
as in:
Spermatheca Cross-section = Cross-section of the Spermatheca.

The schema tool will by default show the hierarchical representation of the actual structures.  Thus one would see Spermatheca in the hierarchy, but not its perspectives.  However, the user or designer can opt to examine the perspectives of any structure and then the existing perspectives and their properties would be displayed.  The designer can add perspectives to any structure, as needed to enter data.

Since perspectives have basic properties, within the database itself <structure-name> <type> will serve as its database name.  From the Entity-Relationship model (Chen, 1976), both entities and relationships between entities are ultimately represented in the database as if relationships were also entities.  The reason is that both entities and relationships have properties.

2. Junctions

A junction consists of three components: the term 'Junction', and the names of two structures. 

The textual representation has the following syntax:
'Junction' <structure-name1>/<structure-name2>
as shown in the example:
'Junction' Procorpus / Median bulb

A schema tool should automatically generate a name and common synonyms of the following form:

= Junction of the <structure-name1> and the <structure-name2>
= Junction of the <structure-name2> and <structure-name1>
= <structure-name1> <structure-name2> junction
= <structure-name2> <structure-name1> junction

 which for the example above would automatically generate:

 'Junction' Procorpus / Median bulb

= Junction of the Procorpus and the Median bulb
= Junction of the Median bulb and the Procorpus
= Procorpus Median bulb junction
= Median bulb Procorpus junction

As in the case of perspectives, junctions would appear in the schema tool at the user's/designer's option when viewing the hierarchy of structures.  Within the database, junctions would be treated similarly to perspectives since junctions have properties as well.  The name of the field in the database would be 'Junction of the <structure-name1> and the <structure-name2>'

3. Overlaps

An overlap consists of three or more components: the term 'Overlap', the names of the overlapping structures including the same name repeated when a structure overlaps itself, the name of the overlap if it has one in the literature, and synonyms of the name if they exist. 

The textual representation has the following syntax:

        'Overlap' <structure-name1>/<structure-name2> = <name>

                = <synonym 1>
                =  ...
                = <synonym n>.
 where the <name> and the synonyms are specified by the schema designer. 

An example of the syntax (including an existing synonym) in the schema is:
        'Overlap' Intestine/Anus  = Post-rectal sac

The schema tool will also automatically generate the following synonyms as well.
        Overlap of the <structure-name2> by the <structure-name1>
as in:
        Overlap of the Anus by the Intestine

Unlike what we saw with Junctions, the order of the two structures is important as it would be meaningless to create a synonym such as Overlap of the Intestine by the Anus.

If a particular name, such as Post-rectal sac, is specified and used by the authors for an overlap, this name will be used in the database to represent an entity with properties.  If no name exists in the literature, then the first synonym would serve as the name used in the database.  In terms of displaying overlaps in the hierarchy of structures, overlaps would be handled in the same way as junctions and perspectives.


4.  Groupings or aggregations

Some structures that are separated in the database may be used by some authors as a single structure, which has properties attached to it.

The textual representation has the following syntax:
'Grouping' <structure-name-1> +  ...  + <structure-name-m>
  = <name>
= <synonym1>
=  ...
= <synonym n>

The name and synonyms must be specified, as none will automatically be generated by the schema tool.  Since a grouping has basic properties with states or values, and since a grouping is a relationship between two or more structures, it is converted by the Schema Tool to the entity name in the database using the specified <name>.


5.  Structure contained in several superstructures

Some structures are not entirely contained inside or are not part of a single superstructure but they continue over several structures.  One example is the oesophageal lumen, a tube that starts at the base of the stylet, continues through the various parts of the oesophagus and opens into the intestinal lumen.

Body envelopes and by others in Genital systemA partial substructure consists of three or more components: the name of a structure, the term 'Within', and the names of the partially containing superstructures as in:
         <structure-name 1>
        'Within' <structure-name 2>
        ...
        'Within' <structure-name n>
where the first-named structure (structure-name 1) is within the second-named ones (structure-names 2 to n). 

Since properties can be attached to the structure as it relates to its containing superstructure, field names in the database would have to be generated from each combination, i.e., the name in the database would have the form:
 <structure-name-1> within <structure-name-i>,  i = 2, ..., n,
as in:
 Lumen within the Procorpus
 Lumen within the Median bulb
 Lumen within the Isthmus
 Lumen within the Oesophageal glands

6. Multiple systems for one structure

Some structures (e.g., male caudal alae) can be placed in one system by some authors and in another system by other authors (e.g., caudal alae in either Body envelopes or in Male Genital system). We placed the structure in one of the possible system and we used the relationship 'Also in' to indicate its secondary location.

The textual representation has the following syntax:
[In system 1:] <structure name>, the term 'Also in', >system 2 name>

For example:
Body envelopes / ... / Caudal alae ('Also in' Cuticle)

The schema tool will automatically display the structure name when it is queried about the secondary structure.

7. Muscular and glandular systems

The muscular system includes some muscles whose physiological functions that belong in other systems. For example, the stylet muscles, digestive sphincters, vaginal and spicule muscles belong to other systems (digestive system, genital system). Same thing with the glandular system.

The textual representation has the following syntax:
To be defined later.

The schema tool will use database 'views' to display on demand the lists of structures comprising the glandular system or the muscular system.

8. External morphology

Some structures in various internal systems open to the outside and these openings must appear in the external morphology, under the corresponding body parts. 

The textual representation has the following syntax:
'Also in' relationships are used to support the 'external morphology' view.

The textual representation has the following syntax:
To be defined later.

The schema tool will use database 'views' to display on demand the lists of structures comprising the glandular system or the muscular system.

9.1 Basic properties depending on the observation material used

The textual representation has the following syntax:

<structure name>, basic property name, <specifying wording>

 

For example: Face view, shape - by LM, by SEM


The corresponding function in the Schema Tool will be defined later.


9.2. Basic property "position relative to"

The textual representation has the following syntax:

<structure name 1>, the words 'position relative to', and <structure name 2>

 

Example:

Labial disc, position relative to - {Lip region}

 

The corresponding function in the Schema Tool will be defined later.