nLab ontology log

Idea

An ontology log (“olog”, spoken like “o log”) is a labeled graph with an attitude: vertices are labeled with ontological types and edges are labeled with aspects of ontological relationships. The path category of an ontology log is a diagram with an attitude, representing an ontology which can be interpreted in a chosen setting. Non-trivial ontological facts can be added as path equivalences.

Ontology logs provide a basis for database construction. In particular, an ontology log can serve as the schema for structured data.

As originally introduced in (Spivak & Kent 2012), ologs are diagrams into Set or another topos. However, as they anticipated, and as later realized by (Patterson 2017), ologs can be generalized to diagrams into Rel or another bicategory of relations, and as elaborated by (Lambert & Patterson 2024), ologs can also be generalized to diagrams into double categories.

Definition

An ontology log is a commuting diagram. Three flavors of ontology log are known:

1. functional ologs, which target topoi;
2. relational ologs, which target bicategories of relations; and
3. double ologs, which target double categories.

The labels of the diagram are expected to adhere to language-specific good practices. Labeled objects, arrows, and 2-cells are called types, aspects, and facts respectively.

Target categories are called data categories and functors from ontology logs to data categories are called instance data. (Patterson 2017, p. 26)

English

These rules are enumerated in (Spivak & Kent 2012) as “good practices” which should be followed but may be distorted or ignored as part of authorial intent.

Types

Type labels should:

1. begin with “a” or “an”,
2. refer to a distinction which the author can demonstrate,
3. also refer to a distinction which is inhabited and definable,
4. not end in punctuation, and
5. declare any variables or free parameters using subordinate “where” clauses.

Aspects

Aspect labels should:

1. begin with a verb,
2. yield a grammatical sentence when prefixed by its source label and suffixed by its target label, and
3. express a functional dependency.

Facts

Facts do not need to be labeled, but the author should indicate as many of them as they know about, even facts which seem simple or trivial.

Properties

(…)

Examples

(…)

References

• DI Spivak, RE Kent, Ologs: A Categorical Framework for Knowledge Representation, PLoS ONE 7(1) 2012 [arxiv:1102.1889, doi:10.1371/journal.pone.0024274]
• E Patterson, Knowledge Representation in Bicategories of Relations, 2017 arxiv:1706.00526
• M Lambert, E Patterson, Representing Knowledge and Querying Data using Double-Functorial Semantics, [arxiv:2403.19884]