Rough list Modelling Guidelines

FuGE Best practices describes key points to follow when extending FuGE to a particular technology.

1. When creating a new matierial type extend from the Material class when:

A Protocol Application will act on it;
The material is a component of another material which has additional
- descriptors that must be attached;
When the material modeler knows in advance what properties will be required

2. Do not extend material class when:

Atomic concepts may be encoded as an ontologyTerm.
Where there is variability in what might be an input to a
- ProtocolApplication, or the developer does not know in advance what properties might always apply - use GenericMaterial

3. Do not add a Type association to material, use the inherited association

1. Acts a proxy for a database entry to represents a biological entity that

is being detected or acted upon in the experiment. It should be extended when additional properties are required in the local FuGE representation
rather than what can be retrieved solely using DatabaseEntry.

1. Within model use whichever names are required for entity and association ends.

Any clashes will be resolved later. There is no effort from FuGE to fix naming clashes.

Other suggestions: Protocols should be verbs? Materials should be nouns? Roles start with uppercase, associated ends lowercase?

1. Buffers and solutions should usually be represented in Protocols

using Parameters. If things parts of a buffer / solution change in different experiments, this can be encoded as runtime parameter values. Exception, if it has some properties that may be measured for example, or it deteriorates, and some values may be recorded then it can be
recorded as a GenericMaterial for each ProtocolApplication.

1. Where additional metadata is required, that cannot be encoded in FileFormat

or ExternalFormatDocumentation, and cannot be retrieved easily from the file (i.e. to avoid redundancy)

1. Intended as a potentially replaceable value in a protocol 2. It is intended to be atomic

1. For sub-components model these as equipment: when they need a make/model,

if they have their own parameters, or if a Protocol is required to describe a particular assembly of these parts

1. - If something important should be recorded, do not use inherited

Describable. Add an association to Description to communicate to users / developers that something is required .

1. Do not model starting sample before it is specific to this particular

technology in the pipeline i.e. the concept of starting/Biosample is out of scope of technology extensions

2. The starting point for each Protocol Application should be a reference to

Material for the starting sample. This will allow models to be integrated more easily in an overall sys-bio framework.

1. If it exists outside of any particular InvestigationComponent, report

under HigherLevelAnalysis - e.g. clustering on proteomics and microarray data to come to some conclusions about the biology external of any technology

1. Where parts of data within the vendor file need to be related to,

for example, input parameters, reference the file as ExternalData. Build a wrapper (Class) around the format that relates part of the data, where possible, to input parameters.