Document status. This document is informative. It provides guidance and instructions for creating and using utility (or shortcut) properties; it does not define a normative standard and imposes no conformance obligations. It uses RFC 2119 keyword syntax (MUST, SHOULD, MAY, etc.) to signal the strength of each instruction. Sections 1 through 6 are stable. Section 7 (Naming Rules) is under development; its content is pending and is to be finalized in a future revision. Section 8 (Annotations) is retained from the working draft and is pending revision.

1. Scope

This document provides guidance on the definition, intended use, and recommended practices for utility properties (also termed shortcut properties) within the Industrial Ontologies Foundry (IOF), and serves as guidance for users and implementers of application ontologies based on the IOF.

A utility property is an object or data property that asserts a relation between two individuals while skipping the intermediate individuals and relations that a full IOF/BFO representation would otherwise require.

The intermediate individuals may or may not be present in the knowledge graph, but they can be constructed as needed using SPARQL or other rule-based strategies. In addition, the utility properties can be inferred when the intermediary individuals and relations are present.

This document describes what qualifies as a utility property, the annotations a utility property is expected to carry, and the conditions under which a utility property may be expanded into, or derived from, its full representation. It is intended to guide IOF working groups and adopting enterprises in creating utility properties consistently and without duplication.

2. Status and Use of This Document

This document is informative. It is intended as a set of instructions and recommended practices, not as a normative standard, and it defines no conformance criteria.

The instructions in Section 5 apply, as guidance, to each property that is identified as a utility property (see Section 5.1). A property that is not a utility property is outside the scope of this guidance.

3. Rationale

Utility properties provide a way to assert a relation between two individuals directly, skipping the intermediate individuals and relations that a full IOF/BFO representation requires. Their purpose is to improve the usability of an ontology by reducing the number of triples, axioms, and queries needed to express common relations.

A utility property is not ontologically necessary. It is a modeling and query convenience that abbreviates a longer property chain or logical construct. Because OWL adopts an open-world assumption, a relation acts as a constraint on the world rather than an obligation to materialize every intermediate individual. The intermediate individuals and relations therefore need not exist in the knowledge graph; where a use case requires them, they can be reconstructed (for example, by a SPARQL CONSTRUCT query).

Adopters should treat utility properties as a controlled shortcut: a utility property can always be unfolded into its full path, and the full path can always be collapsed into the utility property.

Differentiation from a Property Chain

A shortcut property may be created without the intermediary individuals and properties being materialized.

4. Location of the Utility Properties

As with property chains and SWRL rules, we will place them in the non-normative addenda areas. The utility properties will be in an ontology named after the domain they address.

Location: <domain>/addenda/utility/

There is an existing example in the following location: core/addenda/utility/PrescribedAllenIntervalAlgebraUtility.rdf

5. Instructions for Utility Properties

A utility property is identified by the isUtilityProperty annotation. The instructions in this section apply, as guidance, to every property so identified.

5.1 Identification

A utility property MUST carry the isUtilityProperty annotation with the value true.

A property that is logically defined by a property chain, rule, or query, and that exists as a modeling or query convenience, MUST be identified as a utility property under 5.1.

5.2 Expansion and Derivation

A utility property MUST provide at least one of the following:

• a property chain that defines it; or

• both the utilityPropertyExpansionQuery annotation and the utilityPropertyCreationQuery annotation.

The expansion query, where present, MUST expand the utility property into its full IOF-compliant representation. The creation query, where present, MUST derive the utility property from a full IOF/BFO-compliant representation.

Define, in SPARQL, SWRL (deprecated standard), or SHACL, the process for materializing the intermediary individuals and properties. Cascading restrictions.

5.3 Labeling

A utility property MUST carry a human-readable label (rdfs:label).

A utility property MAY carry one or more alternative labels (for example, a more user-friendly form of an ISO/IEC 11179 name).

5.4 Use and Warning

A utility property MUST be treated as non-normative within the adopting ontology and SHOULD be accompanied by a warning that its use may carry modeling or reasoning implications.

Where a use case requires the intermediate individuals and relations that a utility property skips, they MAY be materialized from the full representation.

6. Naming Rules

This section is not yet final. The naming rules are to be defined in a future revision. The material below records the current working approach and is provided for information only.

Some are shortcut data properties and some are shortcut object properties.

6.1 ISO/IEC 11179 conventions (working draft)

The working convention is that a utility property name is constructed from the property chain it abbreviates:

Process

• Create a long property name with all the intermediary properties and classes that will be encountered along the chain

  • Begin with the class at the start of the chain.

  • End with the terminal class or data property range.

  • Construct the path with all intermediary classes and properties

• Optimize the name using the examples to derive a shortened name that looks correct.

• A more rules-based method will be provided in the future once a pattern can be derived from existing examples.

Worked illustration:

• ISO/IEC 11179 form: processOccupiesTemporalRegionHasLastInstantHasValueExpression

• Intended (collapsed) form: processHasLastDateTime

• Alternative label: processHasEndTime

Further examples under consideration: portionOfMaterialManufacturingProcessEndTimeValue, personHasBirthdate.

6.2 Open questions (to be resolved)

The following points are unresolved and are the subject of forthcoming work:

• What properties are essential to include in the property chain?

• Can an algorithmic procedure reliably collapse an ISO/IEC 11179 name into a simpler intended form, and is such a procedure necessary?

• Should alternative labels provide the long form of the name or short forms of the name?

• Validation against pilot cases (for example, biopharma certificate-of-analysis temporal relationships, where only a date may be available; and supply-chain "received" relations).

7. Examples

The following examples illustrate the relationship between a full IOF/BFO representation and its utility-property shortcut. They are illustrative only.

Example 1 — End time of a process.
Full representation: a process occupies a temporal region; that temporal region has a last temporal instant; that instant has a value expression; and the value expression carries the time at which the process ends.
Shortcut: process hasEndTime ValueExpression.

Example 2 — Certificate of analysis.
Rather than representing an entire analysis process, an adopter often needs only its start and end times. A utility property can provide direct access to those times while the intervening constructs (for example, the contained measurements) remain available for materialization when required.

Example 3 — Birth date.
Full representation: a birth is a process that occupies a temporal region having a time instant, has participants (for example, a child and a mother), and is associated with a value expression of the relevant time.
Shortcut: person wasBornOnDate DateTime.

8. Annotations

Label: is utility property

Alternative label: is shortcut property

top-level annotation property - just like is primitive. The range is xsd:boolean

Definition:

boolean flag indicating whether an object or data property is logically defined with a property chain, rule, or query

Usage Note:

isUtilityProperty must be present if the property is a modeling or query convenience. The value of the annotation must be set to true. When isUtilityProperty is set to true, the property must follow ISO 11179 naming conventions to indicate its status as a utility or shortcut relation. Also, the property must have either a property chain or the (UtilityPropertyExpansionQuery and UtilityPropertyCreationQuery) annotation properties.

Explanatory Note:

A utility property is not ontologically necessary but serves as a modeling convenience. It can help shorten triples, axioms, and queries. Like a defined class, a utility property can be considered a defined property and hence it is not primitive. It typically represents an inferred or derived relation that abbreviates longer property chains or logical constructs. This flag distinguishes such properties from core semantic properties.

Label: utility property expansion query

annotation property under note

Definition:

SPARQL query that can be used to expand a utility (shortcut) property into its full IOF/BFO-compliant ontological representation

Label: utility property creation query

annotation property under note

Definition:

SPARQL query used to derive a utility (shortcut) property from a full IOF/BFO-compliant ontological statement