IES Common v5.1.0: Disposition Pattern (replaces Capacity Pattern)

[aigora-de]

This pull request is suspended until a plan for addressing the issues raised in comments is made and development resources assigned

IES Common v5.1.0: Disposition Pattern (replaces Capacity Pattern)

Summary

Following reviewer feedback, this PR supersedes the Capacity pattern proposed in PR #17 v5.1.0-rc2 (Part 2). It
introduces a revised treatment of the requirements for recording what things can do — their potential — within IES Common.

For visibility, the requirements and analysis document disposition-pattern.pdf is included in content covered by this PR.

The existing ies:DispositionalClass, ies:Capability, and ies:Tendency
meta-classes are retained without change. This PR is additive and
non-breaking: no existing data or implementation is affected.

---

What Has Changed from rc2

Terminology

The rc2 proposal used ies:Capacity, hasCapacity, and eachHasCapacity. This
PR replaces that terminology throughout:

rc2 term	This PR
ies:Capacity (new class)	Not introduced — ies:Capability retained
hasCapacity	ies:hasDisposition
eachHasCapacity	ies:eachHasDisposition

The collapse of Capacity into Capability is because the two classes were found to be semantically equivalent (see §5.1 of the disposition-pattern.pdf). No new meta-class is introduced.

Withdrawn Claims

The following claims made in rc2 have been acknowledged as overclaims and are
withdrawn:

• "Better alignment with modal logic" — no formal correspondence with any
  specific modal logic system was established. The defensible claim, supported by
  analysis, is that the new properties make modal intent more explicit in the RDF
  structure (see §6.3 of the informational analysis).
• "Clearer spatio-temporal semantics" — this was poorly argued. The State
  domain provides spatio-temporal anchoring as a consequence of the encoding
  choice, not as a claimed improvement over the existing mechanism (see §6.4).
• "Capacities attach to States not whole-life Entities" — this was misleading.
  Whole-life Entities are first-class disposition bearers under the proposed
  encoding, because every Entity subclass in IES v5 is also a State subclass
  through the Entity-as-State pattern (see §6.2).

Aspect 1 - Modal Potential

Part 1: The Existing Encoding (Retained)

The existing ies:isDisposedTo and ies:allHaveDisposition properties remain.
Under Interpretation 2 (where the modal semantics are carried by
the property rather than embedded in class definitions), and with
State/ClassOfState semantics, they address requirements §3.1–§3.4 of the
informational analysis.

This PR does not deprecate or restrict the existing encoding. Implementers may
continue to use isDisposedTo and allHaveDisposition without change.

---

Part 2: Proposed Refinements — Two New Properties

Two new properties are proposed as backwards-compatible additions alongside
the existing encoding:

ies:hasDisposition

ies:hasDisposition a owl:ObjectProperty ;
    rdfs:label "has Disposition"@en-GB ;
    rdfs:comment """Asserts that a State (or Entity, which is also a State in IES) can, in some possible
        world, have a temporal part that is a member of the specified ClassOfState.
        This is the individual-level disposition assertion."""@en-GB ;
    rdfs:domain ies:State ;
    rdfs:range ies:ClassOfState ;
    rdfs:subPropertyOf ies:relationship .

Usage: Individual-level assertion — "Fighter XYZ-123 can fly at Mach 2."

data:FighterXYZ-123 a ies:Aircraft ;
    rdfs:label "Fighter XYZ-123"@en-GB ;
    ies:hasDisposition ex:FlyAtMach2 .

ies:eachHasDisposition

ies:eachHasDisposition a owl:ObjectProperty ;
    rdfs:label "each Has Disposition"@en-GB ;
    rdfs:comment """Asserts that every member of the domain ClassOfState can,
        in some possible world, have a temporal part that is a member of the
        range ClassOfState. This is the class-level disposition assertion."""@en-GB ;
    rdfs:domain ies:ClassOfState ;
    rdfs:range ies:ClassOfState ;
    rdfs:subPropertyOf ies:relationship .

Usage: Class-level assertion — "Every Eurofighter in operational condition
can fly at Mach 2."

ex:OperationalEurofighterState a ies:ClassOfState ;
    rdfs:label "Eurofighter in operational condition"@en-GB ;
    rdfs:subClassOf ies:VehicleState ;
    ies:eachHasDisposition ex:FlyAtMach2 .

Why these properties alongside the existing ones?

The structural difference is in where the modal semantics reside:

• Under the existing encoding, isDisposedTo is a sub-property of rdf:type.
  This forces the modal content into class definitions (e.g. "Vehicles capable of
  Mach 2"), introducing definitional circularity and making modality invisible to
  automated reasoning — the triple data:FighterXYZ-123 rdf:type ex:VehiclesCapableOfMach2
  is indistinguishable from an ordinary type assertion.
• Under the new encoding, hasDisposition carries the modal semantics
  independently. The Capability class can be defined cleanly as a class of states
  ("states of flying at Mach 2"), and a SPARQL query or consuming application can
  distinguish disposition assertions from type assertions by graph structure alone.

Both encodings express the same set-theoretic relationship (Sₓ ∩ R ≠ ∅).
Neither is more "correct" than the other; they differ in where the semantic
complexity resides and how visible modality is to consuming systems.

---

Coverage: All Three Planning Levels Supported

A concern raised in rc2 review (chrispartridge1091, issue #35) was that the
proposal excluded the non-specific asset case used in mission planning. The proposed encoding covers all three levels:

Level	Description	Mechanism
Non-specific	"Some class of asset can fly at Mach 2" — type not yet identified	ies:Capability instance + SPARQL query over eachHasDisposition
Class-level	"Every Eurofighter can fly at Mach 2"	eachHasDisposition on a named ClassOfState
Individual-level	"Fighter XYZ-123 can fly at Mach 2"	hasDisposition on the Entity or a State of it

For the non-specific case, a named asset class is a convenience, not a
requirement:

# A SPARQL query retrieves all classes whose members have the Mach 2 disposition
SELECT ?class WHERE { ?class ies:eachHasDisposition ex:FlyAtMach2 . }

# And all individuals
SELECT ?asset WHERE { ?asset ies:hasDisposition ex:FlyAtMach2 . }

---

Whole-Life Entities

Whole-life Entities are first-class disposition bearers. A whole-life Entity such
as data:FighterXYZ-123, typed as ies:Aircraft, satisfies the ies:State
domain of hasDisposition directly — because ies:Aircraft is a subclass of
ies:VehicleState, which is a subclass of ies:State.

Temporally scoped assertions (for capabilities that hold only during a specific
period) are made by creating an explicit State instance with temporal bounds:

# Whole-life assertion — no temporal scoping needed
data:FighterXYZ-123 a ies:Aircraft ;
    ies:hasDisposition ex:FlyAtMach2 .

# Temporally scoped assertion — capability assessed for a specific period
data:FighterXYZ-123-Operational-2025 a ex:OperationalEurofighterState ;
    ies:isStateOf data:FighterXYZ-123 ;
    ies:inPeriod data:Year2025 ;
    ies:hasDisposition ex:FlyAtMach2 .

---

Aspect 2: Dependency Properties (For Discussion)

The two new properties above address Aspect 1 of the requirements: modal
assertions of potential. They do not address Aspect 2: the compositional
constraints that describe what must hold for a potential to be realisable (e.g.
"a Eurofighter flying at Mach 2 requires both EJ200 engines to be operational").

The informational analysis (§5.3) identifies two approaches for Aspect 2 and
brings the choice to the IES-TG:

(a) Four dependency properties extending the disposition vocabulary:

Property	Domain	Range	Semantics
ies:requires	State	ClassOfState	This State requires co-occurrence of a member of the range class
ies:eachRequires	ClassOfState	ClassOfState	Every member of the domain class requires co-occurrence of a member of the range class
ies:requiresPart	State	ClassOfState	This State requires a mereological part that is a member of the range class
ies:eachRequiresPart	ClassOfState	ClassOfState	Every member of the domain class has a mereological part that is a member of the range class

A worked example of this approach is provided in Appendix B of the informational
analysis, including the Eurofighter propulsion dependency (§3.5) and the
Voyager tanker cross-entity dependency (§3.6).

(b) A separate mechanism rooted in IES's existing mereological vocabulary,
treating Aspect 2 as a compositional constraint problem distinct from the
disposition mechanism.

This PR does not include the dependency properties. They are presented for
IES-TG discussion and, if endorsed, would be the subject of a separate formal
change proposal. The IES-TG's guidance is sought on Questions Q4 and Q5 in
§7.3 of the informational analysis.

---

Known Limitations and Deferred Items

Item	Status
Event-bearing dispositions	The State domain excludes ies:Event in v5. No use cases identified. Under Top and Core (v6), Activities are States and the distinction dissolves. Existing isDisposedTo (domain ies:Element) covers this if needed in v5.
Prohibitions	Neither encoding provides a mechanism for asserting that something must not exercise a potential. Deferred; likely requires a dedicated complementary mechanism.
Measured and quantified dispositions (§3.7)	Qualitative dispositions only in this release. Quantified dispositions (e.g. "can carry up to 6,500 kg") are identified as future work requiring combination with IES's existing Measure and Attribute patterns.
Dependency properties (Aspect 2, §3.5–§3.6)	Whole-part and cross-entity dependency properties (requires, eachRequires, requiresPart, eachRequiresPart) are presented for discussion but not proposed for inclusion in this release.

---

Questions for IES-TG Review

From §7.3 of disposition-pattern.pdf:

Q1. Does the IES-TG agree that the seven requirements in §3 are the right
set? Are there requirements that should be added, removed, or reframed?

Q2. Does the IES-TG accept the distinction between Aspect 1 (possible worlds
/ modal assertions about potential) and Aspect 2 (designs and plans /
compositional constraints) as the right way to structure further work?

Q3. Does the IES-TG agree that the existing isDisposedTo /
allHaveDisposition mechanism, under Interpretation 2 and with
State/ClassOfState semantics, addresses requirements §3.1–§3.4?

Q4. Should hasDisposition and eachHasDisposition be taken forward as a
formal change proposal for inclusion in IES Common? If so, should they be
proposed for v5.x (a minor release) or deferred to v6?

Q5. How should requirements §3.5–§3.6 (dependency properties) be addressed?
(a) Extend the disposition pattern with four dependency properties? (b) Use a
separate mechanism rooted in mereological constraints?

Q6. Is the deliberate exclusion of Event-bearing dispositions from the v5
scope acceptable, given that no use cases have been identified and that the
distinction dissolves under Top and Core?

---

Issues Addressed (for discussion)

Issue	Resolution
#31 Whole-life Entity capacity incorrectly restricted	Addressed: State domain accommodates whole-life Entities via Entity-as-State pattern; documentation rewritten (§6.2 of analysis)
#32 Modal logic claim unsupported	Addressed: claim withdrawn; replaced with precise encoding-explicitness claim (§6.3, §7.2)
#33 Capacity class not needed	Addressed: Capacity class not introduced; ies:Capability retained; properties renamed to hasDisposition / eachHasDisposition
#34 Pattern framed as 4D improvement (category error)	Addressed: framing corrected; set theory and possible-worlds semantics established as the shared foundation in §4; "4D coherence" claim withdrawn
#35 Case 3 (non-specific assets) unaddressed	Addressed: all three planning levels (non-specific, class, individual) are covered by the proposed encoding; demonstrated via SPARQL in §5.2.3
#36 Relationship to ies-possibilia undocumented	For discussion: dispositional vs epistemic modality distinguished; complementary roles of disposition properties and ies:PossibleWorld documented in Appendix A.4

---

Documentation Changes

• docs/common/user-guides/capacity.md — replaced with revised user guide disposition.md
  reflecting the corrected framing, hasDisposition/eachHasDisposition
  terminology, and all three planning levels
• docs/common/glossary.md — entries updated
• specification/ies-common.ttl — ies:hasDisposition and
  ies:eachHasDisposition property definitions added; no new classes introduced

Sample Data

• docs/common/examples/sample-data/disposition-class-level.ttl
• docs/common/examples/sample-data/disposition-individual-level.ttl
• docs/common/examples/sample-data/disposition-conditional.ttl

[Matteo-Benocci-Semantic-Partners]

ies:hasDisposition a owl:ObjectProperty ;
    rdfs:label "has Disposition"@en-GB ;
    rdfs:comment """Asserts that a State (or Entity, which is also a State in IES) can, in some possible
        world, have a temporal part that is a member of the specified ClassOfState.
        This is the individual-level disposition assertion."""@en-GB ;
    rdfs:domain ies:State ;
    rdfs:range ies:ClassOfState ;
    rdfs:subPropertyOf ies:relationship .

Just some minor worries about the definition of ies:hasDisposition: it is redundant - or, at the worst, logically confusing, to say that it "can in some possible world", since the whole point of using a possible worlds apparatus is to analyse possibility. Instead, we should say that the state "has, in some possible world, ....". Even better, we could write "in some possible world has a counterpart that....", since in a modal realism framework it is inevitable to use a counterpart relation for singling out elements across possible worlds.

[Matteo-Benocci-Semantic-Partners]

A general perplexity about the examples used here. Even though the examples concern the relations ies:hasDisposition and ies:allHaveDisposition, the fighter's case seems to be more about a capacity.

The differences between capacities and dispositions can be tricky to analyse; however, the main differentiator is that dispositions are individuated not only by a manifestation or effect, but also by the stimulus that triggers that manifestation or effect. For example, water-solubility is a typical example of disposition because it consists in the tendency to dissolve when put in water. In addition to that, an object having a disposition entails that it prevalently produces the effect in question when the trigger occurs: sodium chloride is most likely going to dissolve when put in water - unless some other chemical preventing the dissolution is added.

By contrast, a capacity ascription merely entails that an object can do this or that, without any implications about the conditions in which it does it or about how likely it is to do it. In the examples above, there is talk of aircrafts being able to fly at a certain speed, which seems to point to a capacity more than a disposition.

I don't know what you had in mind when you were constructing the fighter example, but the problem might just be in the phrasing: maybe what we really mean what we say that a fighter can fly at Mach 2, is that it is disposed to fly at Mach 2 when certain operations and conditions are met - that is, is properly fuelled, is in clean configuration, and so on. I suspect that this might be the case, since we are not interested in what an aircraft "can" do, but in what it tends to do when configured and used in a certain way.

[Matteo-Benocci-Semantic-Partners]

NB if you grant my point about the disposition vs capacity distinction, this would also require a revision of the definition of ies:hasDisposition: the disposition that you have proposed above sounds more like a definition of ies:can.

[afizzycola]

I recommend this PR is rejected because of the following:

1. It is not clear what the new disposition semantics add to what is already covered in the standard (specifically the Dispositions pattern) and through rdf and rdfs.
2. The examples provided do not follow patterns and stipulations stated in the standard. Moreover some examples contradicts guidance.

Please see my code and file comments for further details

[afizzycola]

why are there dotted isDisposedTo lines as well as the <<objectProperty>> UML element? Same with allHaveDisposition

[afizzycola]

What is an anonymous planning asset class? These examples don’t feel very accessible from the perspective of an everyday IES user. I’d suggest using the comments to better explain what you’re trying to achieve here, especially for someone approaching this topic with no prior context.

[afizzycola]

why is ies:eachHasDisposition a blue ObjectProperty? This implies it is a subProperty of rdfs:subClassOf but in the .ttl it is a subProperty of ies:relationship. Which is it?

[afizzycola]

This is applies to all the newly introduced relations as in the RDF they seem to be just subProperties of ies:relationship

[afizzycola]

If each instance of ex:EurofighterInOperationalCondition has the disposition of ex:FlyAtMach2 then ex:EurofighterInOperationalCondition is a subClassOf ex:FlyAtMach2. You don't need this new ies:relationship

[afizzycola]

What makes this different to the above ex:FlyAtMach2?

[afizzycola]

Data for justifying this? Again this is staying into what rdfs domain and range; and SHACL are for

[afizzycola]

Are we talking about the same dispositions that are covered by ies:DispositionalClass? If so, this contradicts the definition of that class

[afizzycola]

This doesn't seem accurate to me: are they inferences if they are explicitly stated in the ontology as subProperties of rdfs:subClassOf and rdf:type?

[aigora-de]

I suggest replacing "inferences" -> "semantics".

[afizzycola]

I am so confused! What is the difference between these new "disposition" semantics and the existing ones? Looks like the authors have misunderstood the existing dispositions pattern completely

[afizzycola]

Again, what is a conditional class?

[nigel81562]

NB if you grant my point about the disposition vs capacity distinction, this would also require a revision of the definition of ies:hasDisposition: the disposition that you have proposed above sounds more like a definition of ies:can.

Agreed. I think there are at least) three aspects that have been conflated and therefore are confusing. The example of disposition v capability is a good one. Then there is the modal uncertainty which you also point out @Matteo-Benocci-Semantic-Partners. The latter confounds things because just as there is a possible world (set) where something is the case (flying at Mach2) there are worlds where it isn't and indeed where the things don't even exist! All of this irrespective of those thing's capacity to do so. In the case of capability, the uncertainty is around whether it is realised in its lifetime from the narrator's perspective at time t, whereas from outside ontological perspective it is either the case for some state (temporal part) thereof or not. This translates into doxastic actualities (set of possible worlds narrator believes the actual world to be a member of) - but this doesn't get supported until ies-possibilia.

Disposition, on the other hand, could be said to be a property that again may or may not be realised in a lifetime (which could be very long for a grain of salt!) There are possible worlds where salt may not be water-soluble (not a set that includes our world). But this is not the same as capacity to be party to some condition - which I understand the intended use-case is (e.g. car-park to be used as emergency distribution centre). I suspect that capability for something depends on some form of agency to impose the conditions (and interpretation) for the realisation, whereas disposition does not (in general). The disposition is realised in the case of the conditions for it being realised, the event of what something has capacity for is realised if the conditions for such an event are realised.

It seems to me that capacity for something is an observed property for potential to be participatory in some type of event, whereas disposition is an observed material property. The mereology is different. The confusion of modal uncertainty with observer's perspective in the descriptions just confounds things even further. I suggest this PR is rejected for further work. However, in response to questions for TG:

Q1: Aspect 1, ok but needs clarification over modal actuality v possibility (realised v potential to realise)
Q2: Aspect2 - grasps areas for further work but not necessarily the path to be taken - see above.
Q3: No - see above. Could be captured by narrower definitions citing capability to participate in event of...
Q4: No - not is current form. Needs to be worked with capability and with reference to how related to possibility
Q5: (b)
Q6: Yes - as one might guess from suggestion to characterise capability as such to participate in events, mereological distinctions need elaboration and more detailed modelling.

[nigel81562]

Set of things that realise some particular characteristic for some temporal part, and set of things that have the characteristic of being able to realise that particular characteristic, are different sets. The characteristic being citing is different in each case. Therefore the question of realisation should be independent, and the perceived complexity in class disappears.

[nigel81562]

This simply shifts the confusion between characteristic of possibility with possibility of characteristic. It also confounds disposition (integral material condition) with potential to participate in some event - a capability.

[nigel81562]

see comments for hasCapacity / hasDisposition

[aigora-de]

This pull request is "suspended" until a plan for addressing the issues raised is made and resources assigned.