Official site and user guidance
Welcome! We’re all about classifying animal behaviour and cataloguing observations.
On our INTRODUCTION page, you can find out more about our use case, model, and how to participate. If you would like to collaborate, first check out its section: Can I contribute?
Here we will outline our guidelines and rules for contributing to the ontology via the collaborative, online, ontology editor: WebProtégé.
Bear in mind that this ontology has NO COPYRIGHT, so neither will any of your contributions to it (see Licensing page).
Please see the footnote if you want to suggest edits to this website.1
A very early slideshow offers glimpses into the history and utility of WebProtégé.
There is a basic user guide available at WebProtégé. Only one of its screencast links works (the first link below).
Only two useful videos seem to be available to help. One is an early version demo, but it gives a feel for things, although the layout is outdated.
The other is much more modern and gives some ideas about layout and use, in the form of 10 Tips. Tip 9 shows the mechanics of laying out WebProtégé to suit you.
You do not actually need to know how to do much that these guides talk about, as you will be editing a previously set up ontology. Not only will you probably be set up initially to just Comment (see Tip 9 above), but you will be offered support. This may be in the form of a one-to-one online screen-sharing tutorial, if you are invited to collaborate during the Alpha phase.
If you really want to delve into ontology engineering (including desktop Protégé), you can steer yourself through anything that takes your fancy at the OBO Semantic Engineering Training site.
The history tab in WebProtégé will be easiest for future users to follow if every edit is small, containing only a bitesize of material. Working in WebProtégé this will happen automatically. But if the manager approves of editing using an external editor such as Protégé, you will need to save and upload after every significant edit (i.e. not each word, but perhaps after each annotation has been added or edited).
Only if a thematic edit is undertaken offline, multiple edits may be handled in a single save. In due course, we hope to have a GitHub pipeline set up to allow merging of branches (e.g. offline edits in Protégé) with the main file. Commits then will still need to be made very frequently. Over the horizon, we also hope that WebProtégé will be upgraded to allow merges with offline files without using a GitHub pipeline, or directly tied into it instead of being fully stand-alone as at present.
Every edit merged into WebProtégé is called a Commit. It may not be obvious what an edit is doing. Therefore WebProtégé automatically adds a title to each change you make which it merges in, focused on the activity undertaken.
If approved by the manager to do, every Protégé upload will not only overwrite the WebProtégé base file (although it will leave Comments alone), but it will have an unhelpful generic Commit title. This needs to be changed to give a useful idea of what the edit has done, before finishing the upload. Make a quick reference to any prior discussion on the site about the topic. If there is no prior discussion about the change within the history, it may be better to have the discussion first. But if it can’t be helped, then add some reasoning for the change to the Commit.
In due course, we hope to use a GitHub pipeline, or an upgraded version of WebProtégé, for Commits. This will prevent merges into the main file from happening without anyone consenting.
NB: The primordial version of the ontology has been developed as a unitary draft, without edited Commits, but from the ALPHA2 version, the original author also became subject to this expectation.
Your early forays into collaborating may be in the form of Comments only. When you have editing privileges, still consider whether proposing a planned change in the form of a Comment might be the best way to start. (This is a WebProtégé View which does not directly enter the ontology structure.) Try to gain consent, if not consensus. Remember that your edits may be reverted if they appear controversial and have had no discussion. For new terms, make your comment against a parent class if you choose to wait before creating the new class. (Waiting may become the norm if new classes too often have to be reverted.)
Meanwhile, bear in mind that you can view or hide resolved comment threads using the Filter symbol in the WebProtégé Comment View or Tab.
Annotations allow us to understand more about a given class. It may give information about by whom and when it was created, its synonyms, or comments about it, etc. Annotations may have a single sub-annotation level containing similar information. Annotations are added to the ontology via Annotation Property dialogues.
Every class should have a sourced definition, even if it has been interpolated from more general text. Use the Annotation hasDefinition.
For more detailed guidelines, many of which have informed ours below, see the paper onGuidelines for writing definitions in ontologies
Before starting, consider whether your new definition will change the meaning of the class’s ground concept. (The two are not always identical). This can be broadly assessed by considering the existing label, parent, children, siblings, examples, comments, scope notes, properties, and any sources referred to already.
Be more wary if there is already a textual definition and you wish to change it: consider whether your new definition will be inclusive of it (i.e. is your new definition more general, NOT more specific).
Lastly, consider whether your definition will directly aid (or improve) the identification of the behaviour in question. If all these issues are answered positively, go ahead.
NB: A very strict form of ontological reasoning will argue that there is no intrinsic difference between a concept and an accurate axiomatic definition. Therefore changing the concept will necessarily require changing a logical definition, which must necessarily require creation of a new term. However, humanly useable ontologies like ours do not fully axiomatise their ‘ground concepts’ in the form of logical definitions. Because they are not written strictly for machine learning, what we are doing is generally accepted.
Ignoring the parts in (rounded brackets), use the construction: (X is a) Y [that / when / in which / wherein] Z.
Use the immediate binomial or trinomial for Y if it will aid understanding, e.g. (gathered-suspended is) an unsupported placement that…
NB: A class definition’s genus is its parent’s binomen, although this may be abbreviated to the parent’s first name if the meaning is clear.
Where a source is essentially being quoted for the definition, sub-annotate with rdfs:isDefinedBy and skos:scopeNote (quoting the whole sentence or sentences from which the definition is drawn). There is no need to add dc:contributor as a sub-annotation to the definition, but by all means add it as a top term Annotation.
Limited edits may be needed, such as modifying word endings, or cutting and splicing very close elements contained within a single sentence (or possibly adjoining sentences), and preferably without reversing word order.
A quoted definition may be made more parsimonious by dropping a superfluous component, but not if it simply generalises the definition (i.e. not if the dropped component would effectively create a sub-division). Word changes should also be avoided, particularly if the definition would be made more generic (e.g. by changing ‘fish’ to ‘animal’).
Otherwise, even if the bulk of the definition comprises quotes, use hasDefinition, with dc:source and dc:contributor as sub-annotations (and avoid rdfs:isDefinedBy).
Where more than one source is used to create a definition, give each as a sub-annotated dc:source. This should only rarely be needed.
REMEMBER: Every definition must be sourced, even if not quoted.
To expand the definition beyond its essential core, use additional text following a full-stop (rather than a comma, colon, or semicolon).
Do not use the term label or its root within its own definition, unless in a clarifiying sentence after the first full-stop. An exception may occur where the label is apparently partly composed from its actual or potential ontological parents, parts, participants, or attributes (e.g. terrestrial-lateral-undulating). Another exception is where the label is one of a set of invariant and exclusive subdivisions (e.g. spawning may only involve eggs or sperm). In any case, remain open to adopting alternative terminology.
NB: Some judgement may be needed about how far back roots should be sought (e.g. are feign and feint from separate French words or the same Latin word), but try to avoid a debate if possible.
The ontology has adopted a single parenthood policy, with subsidiary parthood. Multi-parenting for new terms should be avoided.
Using a synonym in a simplistic definition is tempting and perhaps unavoidable at times. But it is too close to being tautology, and should be avoided if possible. (The definition is ideally some kind of expanded explanation.)
Consider changing such a synonym type to hasRelatedSynonym as a workaround which will also highlight its deliberate use, but don’t just delete the synonym in order to reintroduce it to the definition.
Synonyms should be sourced and dated by year. They can have modified suffixes to match the class label in question.
Choose the annotation property which is most suitable, when labelling synonyms. Remember that any one may in future be challenged, so consider a justifying comment or quote:
If you wish to promote a synonym to the main label, justify this and try to engage in discussion before implementing any change; remember also to relegate the label to a synonym.
The same word may have different meanings in different sources. The binomial system of term labelling should prevent overlap, but preferably also use hasRelatedSynonym if the same word is being used as a term label elsewhere.
It is not our role to judge the validity of an assertion. Before considering incompatibility, be sure you are not better served with a Synonym.
However, scientific ideas evolve and new ideas emerge which may be incompatible with former ones, and we need to be able to differentiate these assertions from one another. With sufficient consensus, an rdfs:Comment can be added to the effect that it is an INACTIVE TERM or a HISTORICAL TERM, simply meaning that it should not be used for ongoing annotation. Where a concept is directly criticised in a source as obsolete, defunct, or a similar appelation, consider using the annotation property ‘skos:scopeNote’ to quote or summarise the criticism, along with ‘dc:source’.
If incompatibility is clear, then create a new term. Annotate both with rdfs:seeAlso.
In OWL syntax, we can also annotate a term as OWL:deprecated, which means it will appear crossed-out, yet will not disappear from the ontology, and remains visible to the reasoner. It also means the ID will not be reused, so there will be no confusion over its edit history. This process should be reserved for terms which appear to have been created as curation errors.
Don’t simply hijack a label, since the term history could become incomprehensible. Instead consider alternatives which preserve the old and the new. For example, give a clarifying word after a hyphen in the label, although try to relate it to the clarifying author (e.g. ‘migrating-Smith’ and ‘migrating-Jones) or concept, rather than simply ‘-old’ and ‘-new’. Some new concepts will come with their own new labels. If you must reuse a label for the new concept, ensure the deprecated term has some label in addition to its old ID number.
This whole topic may be revisited in due course.
An Instance is a unique example of a class being used. In our case, it will be a particular behavioural label as applied to a specific Observation (a photo, recording, video, or other artefact). This will have been archived in a permanent (if possible), specific, sign-posted (e.g. a URL), publicly accessible location outside our ontology (online if not a physical artefact, and not embedded in our ontology). While the item may be reused (e.g. for several different behaviours), the Instance is unique (being the only use of the particular behavioural label to the particular item).
iNaturalist is designed to host hundreds of millions of observations. The Active Animals (AA) project there can leverage its capabilities to catalogue large numbers of examples. Our ontology is not designed to duplicate that cataloguing function. The Instances we hope for in this ontology are of two kinds:
Links to scientifically robust external resources which illustrate a behaviour, to aid in understanding it, and to aid in identifying the behaviour in one of our field observations. These links should be provided judiciously, and only multiplied in a specific class where they extend understanding beyond previous Instances; they should not simply be added on a taxonomic basis, although taxonomy may be an underlying reason to multiply illustrations.
Type examples should come from within the iNaturalist catalogue, or other hobbyist repositories (i.e. not scientific sources). They should be offered or agreed to by their originator. Once added, they should not be changed without a discussion.
Where a class has no subclasses (i.e. it is a leaf or terminal class), a new Instance can be considered. Where a class has subclasses, Instances should only exist to illustrate key elements missing from the subclasses. Otherwise, it is redundant and should be deleted unless justified in an rdfs:comment.
Use the Individual tab in WebProtégé, or the Individuals by Class view in any tab in WebProtégé, to add details of the Instance to the relevant class.
Your new class should represent a unique concept, not merely a unique label. Indeed, the label could be changed later, but the ‘thing’ that is the class should never change. (If it is superceded later, it may be deprecated, and a new class should be created, even if it has the same label, and a link can be made to the deprecated class to show it has been replaced.)
Search the ontology thoroughly for classes which may duplicate your concept, even if using different wording, and if they need modifying without changing the inclusive meaning, an edit there may be the best way forward.
Except in justifiable cases (e.g. ‘instinct’ which has a long pedigree and is widely known), try not to create new classes just to suggest they are inactive. Our initiative is not trying to track every discredited idea that has ever been dreamt up about behaviour, but ideas which help explain where we are now, and how we got here.
An almost infinite array of compound terms is possible. We need to limit this:
If you want to create new terms, ask the manager to allocate you a batch of ID codes (these are then applied automatically).
Select a parent class (you can change it later), click the Create button, and write a label which is unique to the behaviour branch of the ontology. (WebProtégé will auto-insert the ID and IRI, and the created_by and creation-date annotations.)
Our binomial labelling system is anthroponymic (quasi-patronymic/matronymic): a class’s first name is novel and its second name is usually its immediate superclass’s (parent’s) first name. (In special disposition-associated cases, where a subdivision involves a single hyphenated name), the part of the name after the hyphen may be carried forward through the sub-branches.)
Among behaviours, every effort is being made to ensure that we only use nouns and gerunds in names, although there will be some (hopefully interim) labels where it is difficult to replace an adjective (e.g. demersal spawning and pelagic spawning). Whilst some labels appear to scan as comfortable adjective/noun combinations because of gerund placements or as familiar adjunct nouns, others will appear jarring word combinations. Remember that the binomen is not designed to be either in principle, and uncomfortable names in this context are expected to crop up often, not least if an adjective/adjunct/noun construction was anticipated but didn’t materialise.
The term itself should be sourced if possible (although a slightly different word form is okay). A sub-annotation should be added with a dc:source. If the term can only (but easily) be inferred from a source, add an rdfs:comment as a sub-annotation.
This section explains which sources or contributors should have priority in our ontology.
Ideally, given our Principles, we want to list the earliest source which references any label or synonym:
The key for a definition is not so much its precedence, as its accuracy, inclusivity, and utility.
Editors who create new terms using the WebProtégé portal will automatically have the date and the creator added, and also an ID number which will remain exclusive to that class despite future edits.
All contributors are encouraged to flag their own inputs with annotation property dc:contributor, preferably using an ORCID ID or something similar, although your name is acceptable (but not just initials or username).
The number of examples should be very constricted, preferably to one overall, but up to one each of the following criteria if necessary. Please don’t delete examples or add a fourth (or more) without a discussion in the relevant page’s WebProtégé comment tab. It should balance:
Most important are production values (clarity, aesthetics, story, etc) and utility (accessibility, comprehensiveness), with age-related features only being key if they have some historical weight (e.g. a classic photo).
This should be the earliest ACTAN-user example that clearly shows the behaviour in question. This is both an incentive and a credit to those of us for whom this is our hobby.
Several key principles apply to successful ontologies. They should be:
open, orthogonal, instantiated in a well-specified syntax and designed to share a common space of identifiers
Accordingly, we have reused some top-level classes defined in other ontologies:
BFO:0000002 continuant, is contradistinct to ‘occurrent’. It lies at the heart of several sub-branches, not least a key ontology called the Phenotype And Trait Ontology (PATO) with its branch PATO:0000001 quality. Continuants should all be imported in this ontology.
Several other imported process branches line up alongside behavior because they too are occurrents, but they are less critical to understanding our ontology terms: ‘environmental system process’, ‘life cycle stage’, and ‘mental process’.
Many of our terms could have been reused from the Neuro-Behavioural Ontology (NBO). However most terms there don’t match our criteria for proper definition, or come without an appropriate external reference. Furthermore, the ontology has not been owned and maintained effectively for many years. Indeed, some efforts have been made to obsolete its terms in favour of near equivalents in other ontologies, or to transfer ownerships to other ontologies, not least from its phenotype branch. Hypothetically, the same could apply to many of the terms on its behavior branch in favour of our ontology. Hence, we have already annotated many terms with a SKOS match annotation, and we would encourage the same consideration to be given to any new ACTAN term. But we do not plan to import any NBO term.
Every parent-child relationship is automatically accorded the inclusion ‘is_a’ (which is invisible to us). Be careful not to introduce circularity by making something a subclass of itself somewhere else in the map.
Also be cautious about the direction of other kinds of relationship (called object properties) you add to a term, as it can affect reasoning if it is wrong (e.g. ‘part_of’ instead of ‘has_part’ can introduce the enigma in which, “all cats are animals and all animals are cats”). Our aim is to keep the number and kinds of relationship simple and limited. Feel free to introduce your argument in a WebProtégé comment if you feel the need for a new one. Only a manager should introduce new kinds of relationship.
Delving under the surface of ontology engineering will reveal two basic types of data: occurrents (in the case of behaviour, these are all processes which may be on or off at any given time), and continuants (in our case, these are generally tangible objects like morphological qualities, which do not behave ephemerally). Some object properties should only be used when relating two terms of the same type. Some only when terms are of different types.
This should only be used when relating two pieces of data of the same type. In our case, one behaviour may has_part another behaviour, because both are occurrents. (Similarly, one anatomical structure may has_ part another one, because both are continuants.)
Bear in mind before adding the relation, that the class which has_ part another class must ALWAYS do so to be axiomatically correct. This is the inverse relation of part_of.
NB: A Reasoner in Desktop Protégé may not flag misuse of this object property, because it is inherently defined rather loosely, and needs additional axioms to raise flags.
This should not currently be used in our ontology to reduce confusion, but would be used when relating two pieces of data of the same type. E.g. one behaviour may be part_of another behaviour, because both are occurrents. (Similarly, one anatomical structure may be part_of another one, because both are continuants.)
Bear in mind that the class which is part_of another class must ALWAYS be so to be axiomatically correct. This is the inverse relation of has_part
NB: A Reasoner in Desktop Protégé may not flag misuse of this object property, because it is inherently defined rather loosely, and needs additional axioms to raise flags.
This should only be used when relating an occurrent to a continuant, and even then, only in one direction (occurrent has_participant continuant). It is strongly defined and Desktop Protégé’s Reasoner should always flag an error.
Bear in mind before adding the relation, that the class which has_participant another class must ALWAYS do so to be axiomatically correct. This is the inverse relation of participates_in.
This should not currently be used in our ontology to reduce confusion, but would be used when relating a continuant to an occurrent, and even then, only in one direction (continuant participates_in occurrent ). It is strongly defined and Desktop Protégé’s Reasoner should always flag an error.
Bear in mind that the class which participates_in another class must ALWAYS do so to be axiomatically correct. This is the inverse relation of has_participant.
This should only be used when an occurrent relates to a realizable entity (a special type of continuant), i.e. occurrent realizes realizable entity.
Bear in mind before adding the relation, that the class which realizes another class must ALWAYS do so to be axiomatically correct. This is the inverse relation of realized_in.
This should not currently be used in our ontology to reduce confusion, but would be used when a realizable entity (a special type of continuant) relates to an occurrent, i.e. realizable entity realized_in occurrent.
Bear in mind that the class which is realized_in another class must ALWAYS do so to be axiomatically correct. This is the inverse relation of realizes.
This should only be used when relating an occurrent to a quality (a particular form of continuant found most commonly in PATO). In our case, a behaviour may has_quality such a quality. (Formally, since has_quality is a sub-set of has_characteristic, the relationship should not work. However, some clever compromises underlying the relationship allow it to appear to work in just this special case.) This will be one of the most common connections our ontology makes to its imported classes.
Bear in mind before adding the relation, that the class which has_quality another class must ALWAYS do so to be axiomatically correct. We will never see its inverse relation, as the aforesaid compromises are not simply reversible.
NB: see Imports.
We can assume certain classes exclude each other, particularly if they are obviously opposites, and need not necessarily disjoint them. We can also add comments if necessary. But disjointing may have profound effects elsewhere in the ontology and we currently avoid them for ACTAN terms. With synonymy, actual homonyms can be separated using our binomial system. (NB: there should only ever be one term with any specific label, which will therefore be the primary binomen user - see Synonyms.)
You can reference an imported class in this ontology. Missing terms can be searched for in OLS and considered for import; the most productive sources so far have been ENVO, PATO and UBERON. If it doesn’t already exist, it could even be given an interim placeholder status provided that a New Term Request is going to be made to a relevant external ontology with a view to replacing our placeholder with the new term import.
The new term must belong to an ontology which offers an appropriate Creative Commons license or equivalent permission. If an as yet unimported term is wanted, check our ontology’s Licenses page to see if the ontology is already covered. The license type will need to be referenced there before an edit can import one of its terms; only an editor with management’s permission can approve the license of a new ontology for import to this ontology.
It is possible to edit imported terms, by deleting superfluous material. But never inject new material into an import and don’t modify the original rdfs:label.
NB: In due course, we expect to expel almost all imported classes, and only provide external links to them in our Annotations.
Feel free to click the ‘View on GitHub’ button, then click ‘Issues’ in the top bar, and create a new one by clicking ‘New issue’. Explain your suggestion and we will look into it. Of course, if you are familiar with GitHub, you can create a branch, make and commit your edits, and create a pull request. If it is more than a simple edit though, we suggest you tie it to an issue so some discussion can be had in advance of the pull request. ↩