CEN4020: Software Engineering I  up ↑

Application Domain Semantic Class Model for International Etruscan Sigla Project

Fall Term 2009

This is a proposed requirements-level class model for the International Etruscan Siglan Project (IESP) system ("the System" for short). The purpose is to name and define the characteristics of the classes of conceptual entities (objects) upon which the system operates. It is not complete, nor is it normative.

Item

The class Item includes every kind of thing (object, entity) in the System to which there may be a reference, either from within the System or from without. An example of the latter would be a citation in a journal article.

This class includes a number of subclasses, such as Artifact, Concrete Siglum, Siglum Abstraction, Symbol, Comment, Collection. Other examples of subclasses may include People, Locations/digs, and Museums.

Each Item has a Primary Class, which the most specifi class to which it belongs.

Item Versions

There must be a way to uniquely identify (refer to) each version of each Item, within the System. The system must prevent "dangling" references (references to Items that do not existin the system).

Items to which there are references must never be deleted. The simplest way to enforce this rule is to distinguished published Items from unpublished ones, and never delete an Item once it is published. Allowing for updates to Items then requires maintaining a versioned history of each Item. This means there must not only be a way of storing all versions (or a trail of crumbs that allows reconstruction of all versions), but there must be a scheme for citing objects that includes the version number. It must be possible also to omit the version number, for a citation that is intended to apply to all versions of an Item.

Creation Dates

In every Item version has a creation date, which is maintained by the system. In other words, editing (modifying) an Item creates a new version of the Item, with a new version creation date.

Originator and Owner

Every item has an Originator (author, creator) and an Owner. The Originator is the Owner, until the Item is published. After publication, the Owner is the System. The Originator is maintained, for historical purposes.

Comment

The class Comment includes a paragraph of text. The Originator of a Comment is also known as the Author. No one but the Author may modify a comment.

Comment Subject

A comment is associated with a unique Item (all versions), called the Subject of the Comment. It is attached to the specific version of the Item that was current at the time the Comment was created, but may be accessed from every version of the Item. It may contain within it embedded references (citations, perhaps like URls) to other Items, so that one can compare and relate the Item to other Items. In order to be able to limit the amount of text that must be stored immediately with a Comment, there should have a provision for a Comment to refer to one or more Documents (another class of Item).

Image

The class Image corresponds to a file containing an image. The other attributes remain to be determined.

Document

The class Document corresponds to a file containing text. The other attributes remain to be determined.

Artifact

  1. A range of years (upper and lower bound) or a single guessed year (upper bound = lower bound) when the Item is believe to have been created.
  2. The location in the world where the item was found. For starters, you may make this a free-format text field. This may be partially or complete blank (for security). Later, to aid in indexing and searching it may be desirable to refine this into fields such as Country, Town or Region, Name of Dig, GPS coordinates.
  3. The location where the actual item is currently stored, and the owner of the physical item. This may be a museum or private physical collection. For starters, you can make this a free format text field. For searching, it is desirable that the reference be uniform for items in the same museum. That way, the address and contact information for the Museum may be stored in one place, and kept up to date. To this end, you should keep a dictionary of Museum names. Later, a class Museum may be added.
  4. A paragraph of free-format text, describing the Artifact.

Collection

The class Collection is an Item that is a set of other Items. The members should be restricted to be all of a single class.

There will be a need for a way to organize the items in a collection. It is not yet clear how this can best be done. One way that does not require any additional mechanism is to construct hierarchical Collections of Collections. For this to work, the attributes of each Collection should include at least:

  1. a Name
  2. the class of Item it contains
  3. a set of Items
  4. a paragraph of text that summarizes what is in the collection

Concrete Siglum

The class Concrete Siglum is an instance of a specific marking or set of markings on a specific Artifact object. A Concrete Siglum's attributes should include at least:

  1. A reference to an Artifact, and a location on the artifact.
  2. A reference to a location in one or more images of the Artifact. At least for photos, the reference should be in a universal form, that might allow a person or software later to find the siglum within the photo. As this point in the design, you can presume that this will be in (x,y) coordinates, where x and y are percent offsets from the lower left corner of the image. That is (0,100) is the upper left corner and (100,0) is the lower right corner.
  3. A paragraph of free-format text, describing the Siglum.

If the Siglum seems to be a sequence of standard symbols (letters, numerals, or other known standard graphemes), the representation in terms of this sequence of symbols may be an additional attribute. To enable this, the system may need to include (as Items) each of these basic standard symbols and (as Collections) each of the alphabets.

A given artifact may have multiple Concrete Sigla. Due to differences in interpretation, the there may be multiple Concrete Sigla, overlappinig, in the region of the Artifact.

It may turn out to be convenient to treat a Concrete Siglum and a Comment as two subclasses of one abstraction -- say, both being classes of a class Artifact Annotation.

Siglum Abstraction

The class Siglum Abstraction corresponds to a conceptual Collection of Concrete Sigla. However, a Siglum Abstraction will probably need some additional information that may not be present for other Collections. In particular, it will probaly require:

    Some explanation of what all the Concrete Sigla in the abstraction have in common
  1. Some sort of schematic of how it is written
  3. A representation as a sequence of letters or other standard graphemes, if it is can be viewed as being composed of such.

Other Possible Classes

T. P. Baker. ($Id$)