Project Proposal

Data Model v0.3, by Zach Tomaszewski

for ICS 691-3, Fall 2001, taught by Dr. Joan Nordbotten

Table of Contents

• Introduction
• Examples
• SSM Data Model
• Description of Entities
• Description of Relationships
• Conclusion
• Appendices
  • Known Design Issues and Future Ideas
    • Entities
    • Relationships
  • Changes from v0.2
  • Wishlist for v2.0

Introduction

The following in a data model for an animal classification system. This system contains multimedia records for many types of animal. The system allows for the construction of a variety of classifications by using Node objects. By adding new classifications or exploring existing ones, users can examine a variety of relationships between animals. They can using alternate classifications, or even intersect different classifications, depending on their current information need. Possible users include junior high students, amateur enthusiasts, researchers, and zoological taxonomists.

Examples

Because of the redundant/recursive use of nodes, this system can be a rather hard to imagine. Here's an illustrative example:

As you can see, the root-node architecture allows for the construction of practically any number of classification systems. There can be any number of node levels; indeed, the Climate Zone classification only uses one such level. (Other likely nodes may be "desert", "rain forest", "tundra", "marine", etc.) Also, I have only shown one branch here of a tree-like structure. At each level of the Linnaean System there are a number of other nodes--many Families under the same Order, many Species under the same Genus, etc. These systems all use the same animal records. (Not every classification system will use all the animal records, however; for example, perhaps someone wishes only to classify snakes on the basis of their venom and how they interact with known anti-venoms.)

Ideally, queries will be able to explore multiple classifications and combine the results. For example, imagine someone compiling an identification guide for marine mammals. Using only the Linnaean System, they would have to sift through all mammals in order to find groups such as whales and dolphins (Order="Cetacea"). Using only a Climate Zone classification that includes a "Marine" zone, they would be swamped with fish, sponge, coral, and other irrelevant animal records. However, if they could intersect these results, they would find whales and dolphins, as well as sea otters, dugongs, seals, and other marine mammals not easily found traversing only one classification system or the other.

Here are some other possible information needs that might be served by this system:

• Are the majority of animals that live in the arctic white in color?
• What poisonous snakes should I watch out for in Botswana?
• Do state birds predominantly come from one certain family or order?

I hope these examples shed some light on the nature of this system.

SSM Data Model

-- SSM model --

Description of Entities

Animal
species_name	<vchar(60)> -- the Latin Genus-species name for this animal
common_name	<vchar(60)> -- the common English name for this animal.
keywords	<vchar(200)> -- keywords describing this animal to aid in searching
Description	<text> -- a description of the animal, perhaps including such things as physical characteristics, habitat, main diet, etc.
Image	filename: <vchar(30)> -- the name of the image file pixel-width: <dec(4)> -- the width of the image in pixels pixel-height: <dec(4)> -- the height of the image in pixels format: <vchar(4)> -- {JPEG | GIF | PNG | BMP} comments: <vchar(500)> -- any comments on the image image: <image> -- a picture of the animal type

The Animal record are the foundation of the system. Each record is like an encyclopedia entry, with photo, text description, and resources for further information.

I have learned an animal's common name may be misleading depending on which field guide one uses or on one's nationality. Species names are, by design, original, unique, and universal (as much as possible, anyway). I have included the species name in the animal record because I think it will probably be used often for direct retrieval.

The complex Image object includes metadata specific to the format of the image. This will be useful for generating HTML on-the-fly. Comments could be sent as ALT text.

Root serves to placehold the top of a classification system. For example, the well-known Kingdom-Phylum-Order-Family-Genus-Species classification is known as the Linnaean System. If this system was being modeled, Root.classif_name would likely equal "Linnaean System".

The nodes will form the bulk of the classification structure and possibly be the most common record type in the database. Type serves to describe the level or taxon of the node. For example, if this were a node somewhere between a "Linnaean System" Root and a "polar bear" Animal record, the taxon_name may equal "Ursus" and the type equal "Genus." (It would then contain another node, taxon_name="maritimus" and type="Species", which would then contain the "polar bear" record.)

Keywords can contain common synonyms for taxon_names. For example, the Genus Ursus node should certainly contain the keyword "bears".

TreeEntity is simply an abstract superclass of Animal, Node, and Root. It greatly simplifies the SSM model by concentrating all the common relationships with Resources and Creators.

I think this is pretty clear. It's just your basic, simple bibliographic record.

These records help accumulate information about who is using the system. Note that there is a username but no password. Users can merely search the system. Since this is not a security issue, there seems no need for passwords that people will just forget anyway.

A Creator is a User who can develop new classification schemes or add animal records. Since the system keeps track of their work, they need a password to login.

Description of Relationships

Since all classifications and animal records are input by Creators, there seems a need for recognition for and control of these creations. The opened relationship is a combination of a creates and a grantsAccess relationship. First of all, the Creator has a link to the entity she has added that identifies her as the original creator. Then, because of this relationship, she also has the power to grant access to other Creators. Those Creators with such granted access to an Entity are then able to edit that Entity. Hopefully Creators will grant access to all other Creators. However, they can also restrict access to only themselves, or any list in between.

Granting access to 0 Creators means granting it to all. This seemed the easiest way to include an "Open to All" option without trying to maintain an index of all possible Creators.

Conclusion

Comments or questions are appreciated!

Appendices

Thank you for reading this far! The following is a list of notes, comments and thoughts concerning current problems and future developments. Though not officially part of this report, comments on these points would be most helpful.

Known Design Issues and Future Ideas

Entities

Animal:

• Keywords could come from a thesaurus, if an appropriate one could be found. I know most Creators will not be skilled at determining their own descriptive keywords from thin air.
• I think the text object should be just plain text. Perhaps some basic HTML could be allowed, such as paragraph, bold, and list tags. Possibly links as well. More than that would likely endanger the web interface.
• The image complex object could be expanded to a multimedia (video, audio, multiple images, etc) in future editions. In this case, where each animal would have a variety of different multimedia objects, a weak entity would serve very well. At this time, I only want one image though.
• Resolution was not included because it's hard to determine; most users uploading the file probably won't know it. Hopefully the system will be able to calculate the image dimensions for the user.
• I see I forgot the imageCite again. I suppose this should be a full-blown relationship between Animal and Resource. Yet it seems more appropriate to be included in the Image complex object. Hmm...

Root:

• Again, some keyword help for users is going to be needed here.
• I think there should be a path attribute that holds where this root should fit in a navigational hierarchy. There are going to a lot of classifications, and so there will need to a classification of them. (scope will help by splitting the roots into two groups.) I'll include this attribute when I know how it will be determined and what it will contain.

Resource:

• There is no bibliographic authority control in this system. Thus, there can be multiple records for the same source. This was allowed so that Creators could include their own notes. (Perhaps a better solution would be into include a Comments field in the cites relationship. But then there would be the whole problem of who insures correctness across the system, and users would have to search for existing records. Though not as suave, I think the current system is easier.)
• These are not weak entities because Creators will likely want to reuse the same sources from different entities.
• I should perhaps include fields such as journal_title and volume_number here.

User:

• I also want a preferences field here to save users' interface personalizations. I don't know what that will look like yet, though.
• People will probably forget their usernames. The system can email it to them at their stated email address.
• There should probably still be a default Guest user for those who want don't want to register. (This depends on system resources; if they're low, administrators may want to force registration to discourage casual traffic.)

Relationships

contains:

• Still debating on that (2,n) cardinality for RcontainsN. Most classifications will have at least 2 nodes. But then, perhaps someone just wants to label a single attribute, such as "egg-layers". But shouldn't this then contain "not egg-layers"? Hmm...
• I have learned that NcontainsN implies a relationship between different nodes. Good; that way a Node won't contain itself.
• Still gotta remember that a Node can contain Nodes or Animals but not both. (I guess I've decided this issue.) Stick in a trigger on that or something.
• Also, every Node must have one and only one parent.
• There will have to be a function defined that traverses these relationships.

opened:

• Issues of scope brought up in v0.2 appendix seem solved. If a Creator is working on a whole Tree, she can pass on access from a certain Node. Once a creator with access creates their own Node under that one, they can in turn pass on access.
• I'm assuming that adding relationships requires access to the parent node.
• I have also included the edited relationship to track changes. This way, a Creator can open an Entity to all, yet still be able to track who did what when.
• I have not extended these relationships to Resources. Perhaps I should. As it stand, it looks like anyone (probably Creators) can add or change an existing Resource. I'll think on this more. Perhaps this can be cleanly controlled by the system outside of the SSM.

Changes from v0.2

• Dropped the Change Log. It takes too much time. Future changes are more important than past changes right now.

Wishlist for Version 2.0

If this system was ever implemented, it would be v1.0. Once it was patched and debugged and working at a basic level, it would be time to start thinking about enhancements and extra features. Here are some of those possible features:

• More multimedia. Sound clips for birds, videos of animal locomotion, diagrams of anatomy, etc.
• Expansion beyond animals and living things.