Capacity and Payload Capacity be made Qualities, not Functions.

[cameronmore]

I suggest that a generic term Capacity be introduced as a subclass of Quality and Payload Capacity be moved accordingly.

A function is the reason that something exists. I am not sure that capacity is the reason for a vehicle to exist. Payload capacity seems to be a 'by-product' of the function of storing or carrying something. The only time a payload capacity might become a function is if someone intentionally builds a vehicle to break some sort of storage record, but even then, the storage or carrying function is really what's being created in the manufacturing of the vehicle, and the capacity is a way of speaking about the physical limit of that function.

Furthermore, what process would capacity be realized in? The payload capacity for a vehicle is the same whether it's empty or full.

I think 'range' also fits this account of capacity (mentioned in Issue 210). I don't think 'range' is the reason for a vehicle or its parts to exist. Certainly, an extended or improved transportation function might inhere in a vehicle and/or its parts, but range is a quality of those artifacts.

There is more to think about with regard to capacities under ideal v. real conditions, like range--the range of an electric car in a cold climate is significantly reduced.

Here is my first attempt at a definition:

Capacity = def. A Quality that inheres in an Independent Continuant or Specifically Dependent Continuant in virtue of its ability to realize a Specifically Dependent Continuant.

The design pattern would be something like this: storage functions bear a storage capacity, payload functions would bear a payload capacity, distance functions would bear a range capacity, and so on. I do not think that this would unnecessarily duplicate the hierarchy, as the difference between the function and its limiting capacity would be used to model very different things. I also do not think we would have nearly as many capacities as we do functions; there seems to be a limited number of common canonical capacities. Storage would cover quite a lot, and be in the same ballpark as occupancy limits for rooms and facilities, a paradigmatic example I want to cover.

There are two objections that I have anticipated.

First, that what I'm modeling is really a disposition and not a quality. In some cases, this may certainly be true, but I'm still not sure what process would realize such a thing as 'payload capacity' since the capacity is the same whether a vehicle or facility is empty or full. While it is true that I'm talking about some material aspect of an entity, I think I'm capturing something distinct from dispositions and functions.

Second, that it's not a good idea to model a negative, which is what storage and payload limits are. I don't think I'm modeling a negative so much as I'm modeling the bound, the limit of a positive. I'm not modeling the 'ability to not carry 100 people in this vehicle' but rather the fact that 'the ability to carry people in this vehicle' has a kind of limit to its full realization. Though I do admit that there is something negative in what I'm doing, I'm trying to capture it in terms of the positive disposition and function.

[dlutz2]

"... Quality that inheres in an Independent Continuant or Specifically Dependent Continuant ...". Can a SDC inhere in an SDC? The range of "inheres in" is Independent Continuant. Or have I missed something.

[cameronmore]

You're right, I used 'or' because I am not sure whether I want to say that the function is what has the capacity or the material entity that has the function has the capacity... I think the latter.

[cameronmore]

Alternatively, to capture what I'm suggesting, we raise Capacity above Quality and allow it to specifically depend on an IC or SDC.

[dlutz2]

Could capacity be the quantification/degree of a function/quality rather than a distinct/separate SDC? We have tentatively adopted the Value Specification design pattern which allows specifying aspects of a quality/function such as quantity.

[jonathanvajda]

A function is the reason that something exists. I am not sure that capacity is the reason for a vehicle to exist.

This just means that it is not a function. It does not follow that it is not a disposition.

Furthermore, what process would capacity be realized in?

Depends on the capacity. Carrying a payload of such-and-such weight and volume is one way realize a payload capacity. I think the issue is that we use terms like 'capacity' and 'capability' differently, whether we are talking about a disposition vs the disposition as to its upper bound realization. It's a subtle nuance.

The payload capacity for a vehicle is the same whether it's empty or full.

By this logic, my ability to play drums is a quality, because whether I play a fast as I can or not at all, I still have the ability.

There is more to think about with regard to capacities under ideal v. real conditions, like range--the range of an electric car in a cold climate is significantly reduced.

Paradigmatic of a realizable entity. Under certain conditions, the entity is realized in a process, but in other conditions the entity is not realized or less likely to be realized.

Capacity = def. A Quality that inheres in an Independent Continuant or Specifically Dependent Continuant in virtue of its ability to realize a Specifically Dependent Continuant.

Abilities are not qualities. Best fit is a disposition. Give some independent reason why any "can"/"is able to"/ability is not a realizable entity?

An ability to realize just is the realizable entity.

Specifically dependent Continuants are not realized. Processes are.

[cameronmore]

The payload capacity for a vehicle is the same whether it's empty or full.

By this logic, my ability to play drums is a quality, because whether I play a fast as I can or not at all, I still have the ability.

I'm not capturing the ability, but something about the ability. Not the ability to play drums but the measurable limits of your ability to play drums.

Capacity = def. A Quality that inheres in an Independent Continuant or Specifically Dependent Continuant in virtue of its ability to realize a Specifically Dependent Continuant.

Abilities are not qualities. Best fit is a disposition. Give some independent reason why any "can"/"is able to"/ability is not a realizable entity?

I want to capture the 'quality' of how a function or disposition may be realized, not those abilities themselves. I want to capture something about the storage function, or about the material entity that bears that storage function, not just the function itself. So no, I do not want to capture abilities, I want to talk about a portion of those abilities. Using the word 'about' here makes me think that the easy way out of this is to relegate capabilities to information-land, but I would rather not do this.

Specifically dependent Continuants are not realized. Processes are.

Realizable entities are realized, what do you mean here?

[Jlbillig]

This sounds like the temperature that affects electric vehicles' distance function (and gas ones) could be represented as process profiles. I don't think capacity can be above a quality because that would entail for every quality of a function, of which there can be many, to be broadened to capacity, which can dull its definition. For example, "The heart has the capacity to pump." comes from its properties/ qualities. These qualities separate the heart from other major arteries that also have the same function capacity but not the same payload capacity. Using adjectives to describe processes are natural language process profiles. "The Teslas distance range got shorter as the temperature got colder," are two process profiles that correlate. I'm not very well versed on capacity stuff but this is how it reads to me, if there's anything to correct please let me know, thanks.

…

On Thu, Apr 4, 2024 at 10:09 AM Cameron More ***@***.***> wrote: The payload capacity for a vehicle is the same whether it's empty or full. By this logic, my ability to play drums is a quality, because whether I play a fast as I can or not at all, I still have the ability. That's exactly what I intend to capture. You can play the drums, but a minivan cannot. Capacity = def. A Quality that inheres in an Independent Continuant or Specifically Dependent Continuant in virtue of its ability to realize a Specifically Dependent Continuant. Abilities are not qualities. Best fit is a disposition. Give some independent reason why any "can"/"is able to"/ability is not a realizable entity? I want to capture the 'quality' of how a function or disposition may be realized, not those abilities themselves. I want to capture something about the storage function, or about the material entity that bears that storage function, not just the function itself. So no, I do not want to capture abilities, I want to talk about a portion of those abilities. Using the word 'about' here makes me think that the easy way out of this is to relegate capabilities to information-land, but I would rather not do this. Specifically dependent Continuants are not realized. Processes are. Realizable entities are realized, what do you mean here? — Reply to this email directly, view it on GitHub <#229 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/A5355457K46HFO6AC3725S3Y3VNH3AVCNFSM6AAAAABFXHVFX2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMZXGMYTQNRWGU> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.*** com>

[cameronmore]

I don't think capacity can be above a quality because that would entail for every quality of a function, of which there can be many, to be broadened to capacity, which can dull its definition.

Capacity could be a sibling of quality, that's what I meant, and this does not affect the disposition or function.

For example, "The heart has the capacity to pump." comes from its properties/ qualities. These qualities separate the heart from other major arteries that also have the same function capacity but not the same payload capacity.

The function of a vein is different from the function of the heart. What I intend to capture is the capacity of amount of blood to flow through a vein or a heart because of its physical size or how 'well' it is performing its function.

[mark-jensen]

I want to capture the 'quality' of how a function or disposition may be realized,

that sounds like a process attribute, eg- profile or characteristic

[swartik]

The discussion seems to be diverging from the original post into threads that use different senses of "capacity". And there are lots of dictionary definitions. Per the Oxford Languages dictionary:

The maximum amount that something can contain.

An amount is a quality. Definition 6 in the OED:

The power, ability, or faculty for anything in particular. 

That's a realizable entity. Other definitions mention measurements.

I think @cameronmore's original post, when he discussed storage functions and their relationships to storage capacities, should still guide us, even if the property descriptions weren't quite right. How about this: A storage function doesn't bear a storage capacity. It specifically depends on a storage capacity. Some material entity bears both a storage function and that function's storage capacity. This pattern both lets you know the material entity's function and provides a measurement of the degree to which the entity supports the function.

A possible objection: you can store supplies in a cave, but storage is not the cave's function. The pattern applies only to artifacts designed for storage.

[cameronmore]

@mark-jensen I could be convinced that a capacity is a process profile, but I don't think that any process needs to occur for a room to have an occupancy limit of 100. The rate of people entering or leaving that room, or the rate of storage space available, would certainly be a process profile of the performance of the storage function of a room, but capacity stays the same. So, even if it's a process profile, it doesn't fit the intended spirit of a process profile. However, if we want to talk about realized capacities, then maybe such a profile approach would make sense.

@swartik agree, and I think I want to include dispositions in my account so we can handle the cave example. The cave has a disposition that allows us to store things in it, just as facilities have occupancy limits even if they have other 'primary' intended functions, hence what I was trying to get at in my comment about capacities being 'by-products' of other dispositions and functions.

There's another question about the 'bearer' of a capacity: it seems like I want to say that the same portions of material that endow a cave with its storage disposition are the same portions that also have relation to this capacity, which is what leads me to think that the actual storage disposition might 'bear' the capacity, but that wouldn't be quite right (but that's just my train of thought).

[jonathanvajda]

A possible objection: you can store supplies in a cave, but storage is not the cave's function. The pattern applies only to artifacts designed for storage.

Bingo. There's a larger literature on capability (similar semantics to capacity). I believe the recommendation is that a capability is a disposition whose realizations are a benefit to some reference class. Or something like that. The notion then would be that a function is a capability. So, bfo:function should have a parent class that is below bfo:disposition. I am entirely sympathetic to adding capability and putting function underneath it. Right now, that's in CCO.

I don't think it has been nailed down: I take capability and capacity to be synonyms in common parlance. Does anyone take issue with this? Translating "storage capacity" to "capability to store" in appropriate? Same for "payload capacity" is equivalent to a "capability to transport material object"? In CCO, there's not many hits for "capacity". Payload capacity is the only one with the term 'capacity' in the label. Many more include 'capacity' in its definition.

@cameronmore made the point as well that we don't want to get confused between the capacity and the measurement of it. That's right. So, if someone said "this Aklaline battery has 1200 mAh capacity", we are talking about a value of a measurement, and that the value of the capacity is at its upper-bound.

So, Cameron, your point is that you want to say "what is the upper-bound, that is being measured? Is this upper-bound not just a quality?"

[jonathanvajda]

I want to capture the 'quality' of how a function or disposition may be realized, not those abilities themselves. I want to capture something about the storage function, or about the material entity that bears that storage function, not just the function itself. So no, I do not want to capture abilities, I want to talk about a portion of those abilities. Using the word 'about' here makes me think that the easy way out of this is to relegate capabilities to information-land, but I would rather not do this.

There is something here about qualities connected to dispositions that is right, but it isn't a parent-class or sub-class of quality it's another relation. The explanatory basis for any disposition existing in a continuant is the quality/qualities that the continuant bears. A change in disposition is grounded in (or at least explained by) one or more changes in the bearer's quality/qualities. When I couldn't play drums, I still had dispositions and qualities, but my ability to play drums was acquired in virtue of changes in dispositions which are in turn grounded in changes in qualities. There isn't some clear differentiae of those qualities that ground my disposition vs those that do not.

Is this what you have in mind? Is this helpful?

[cameronmore]

@jonathanvajda Yes, now we're seeing the same thing. I have become highly sympathetic to adding capability, and it is highly related to a capability/disposition/function. I would say, to be more precise, that a capacity is 'about' the upper bound of any disposition (and subclasses thereof), hence why the measurement value of the capacity is what of primary interest to those using ontologies.

A design pattern I have would be something like this:
Artifact bears Function.
Function realized in Process.
Capacity specifically depends on Artifact
Function has capacity Capacity

The same portions of a cave that give it a storage disposition are the same that yield a capacity to perform that disposition, but the capacity is not the function, but s-depends on the same things that the function does.

Now, there's a whole other can of worms when it comes to producing measurements of those capacities and the fact that they can change over time, but I think this is how it works broadly. My revised draft definition now looks like:

A Capacity is a Specifically Dependent Continuant that specifically depends on some independent continuant and is the magnitude of a disposition to be realized.

[cameronmore]

There are all sorts of axioms we can create around this link of a realizable entity to a capacity. Now along with 'gain of function' and 'loss of function' we could talk about 'increase of capacity' and 'decrease of capacity' and tie them back to the functions and dispositions...

[cameronmore]

I'm thinking that there could be a few top-level capacity classes like Force Capacity and Volumetric Capacity. The former is the Capacity of a material entity to generate, absorb, or displace a certain amount of force and the later is a capacity linked to the disposition to contain or enclose other material. Heat capacity is another good candidate for a top level capacity.

I've also thought of Complex Capacities (or Aggregate Capacities) which are composed of other capacities which are not as fuzzy, like how the manufacturing capacity of a factory is a combination that is calculated from the power of all the machines, the amount of people on staff, and so on. Range capacity might be a complex capacity since it has a lot to do with other elements of vehicles and not just the engine output (like aerodynamics)

However, what I'm calling 'complex capacities' might not be so complex at different levels of granularity, so that approach has its own problems. Like, my disposition to run is a combination of a bunch of smaller muscle-sized dispositions as well as larger organism sized ones, like balance, and so on.

[swartik]

ic describes Vt because Vt has nothing to do with the liquid. It is the class of all volume qualities
that liquid held in the cup can have.

I know you said working with OWL is unnatural, but it's the only language I have. So I need to understand how you
would translate your formulation to OWL. If Vt is a class, you can't assert ic describes Vt (unless you pun, which I assume
is not your intention).

In short, I am asking for agreement on how to express the following two statements in CCO:

1. Cup c is capable of holding a maximum of 1 liter of liquid.
2. Cup c holds 1/2 liter of water.

We can skip temporal constraints for now, although any proposals must be able to accommodate them.

[cameronmore]

Perhaps something like this using the artifact model approach:

Cup has-capacity Vt
Vt prescribed-by CupCapacitySpecification
CupCapacitySpecification rdf:type ArtifactModel
CupCapacitySpecification has-value 1 Liter

And then

Cup participates-in WaterHolding
Liquid participates-in WaterHolding
WaterHolding rdf:type Process
Cup has-continuant-part CupSite
Liquid located-in CupSite
LiquidVolume inheres-in Liquid
LiquidVolume rdf:type Quality
LiquidVolume measured-by RatioMeasurementICE
RatioMeasurementICE has-value 1/2 Liter

(Besides the ICE-IBE links and nodes, which are not the key point here)

[cameronmore]

Alternatively, if we make capacity a class and let the 'limits' relation relate the capacity to the corresponding disposition, then we might get something like this which is similar enough in OWL

Capacity limits some Disposition
VolumetricCapacity subclass-of Capacity
Vt1 rdf:type VolumetricCapacity
Vt1 limits HoldingDisposition
Cup bearer-of HoldingDisposition
HoldingDisposition realized-in WaterHolding
...

And the graph continues from there as outlines above

[swartik]

As I understand @alanruttenberg's approach, the first two lines would be:

Cup has-capacity some (Vt and (has-value value CupCapacitySpecification))

to accommodate Vt being a class.

[alanruttenberg]

[Edit: mistakes: See https://github.com//issues/229#issuecomment-2113570963]

ic describes Vt because Vt has nothing to do with the liquid. It is the class of all volume qualities
that liquid held in the cup can have.

I know you said working with OWL is unnatural, but it's the only language I have. So I need to understand how you
would translate your formulation to OWL. If Vt is a class, you can't assert ic describes Vt (unless you pun, which I assume
is not your intention).

I would have to pun to write that, which is part of the reason I don't think I would bother representing Vt explicitly as a class. But FWIW I have recently had other reasons to consider punning.

In short, I am asking for agreement on how to express the following two statements in CCO:
1. Cup c is capable of holding a maximum of 1 liter of liquid.
2. Cup c holds 1/2 liter of water.

Something like:
(2)
ic1 type value specification (I have asked this to be added to CCO)
ic1 has specified value .5 (ditto)
ic1 uses_measurement_unit
ic1 describes q1 (could use is_a_measurement_of since it probably is)
q1 type volume
q1 inheres_in c
(optionally) ic1 describes c

(1)
ic2 type volume capacity specification
ic2 has specified value 1
ic2 uses_measurement_unit
ic2 describes c

With volume capacity specification defined in text.

Or to have some axioms to defined volume capacity specification:

volume capacity specification subclass of capacity specification
volume capacity specification describes volume (the class, so punning)
or
volume capacity specification subclass of describes some volume (might be a lie, maybe white)

I model the temporal aspect using a time value specification and a relation 'has timestamp' e.g
t1 a time value specification
t1 has specified value

where could be an xsd:dateTimeStamp, or in my case TAI time in nanoseconds, in which case I'd also have
t1 uses_measurement_unit

Finally, associating the value specification with a time
ic1 has timestamp t1

Sorry this isn't all CCO - the value specification pattern is from OBO and I've asked for it and associated relations to be in CCO.

[alanruttenberg]

I think the 747 would have a variety of capacities linked to specific, distinguishable dispositions, like its carrying capacity, its pressurization capacity, and so on. Each of these could have labels like '747 Carrying Capacity' and '747 Pressurization Capacity'.

Yes. I was writing shorthand.

Instances are of type any volume (subclass) less than or equal to what we would call the capacity. I.e. an instance of 1/2 of the 747's volume capacity would also be an instance of 747 capacity

I'm not following what you mean here in the example

Ok. We've identified the 747 volume capacity as a subclass of volume of things that fit in a 747 and superclass of all volume qualities that inhere in the things inside the 747. When I say "identified" I mean that when we talk about capacity what we are actually referring to is that class (call it 747C). So suppose I have a particular - the volume quality of something that fills half the capacity of the 747. That's an instance of 747C. So what should we call 747C? If we called it 747 volume capacity, one might have the impression that any instance of it is the maximum volume the 747 could have. But as I've explained, it not that, it's the volume of anything that fits.

When we say "Universal" that isn't a class. It's a category whose members are classes (loosely speaking). Similarly "Capacity" isn't a class. It's a subcategory of universal.

Now I understand that what feels natural is that the capacity of something is a particular, an instance of capacity the class. My analysis says that the natural thing is a manner of speaking.

We could go beyond BFO and try to reify capacity - make capacity a special class whose instances are standins for classes. That's pushing downward a category to a class, and pushing down a class to an instance. RDF-wise this would be acceptable, with semantics going beyond OWL-DL. Maybe there's even a modified OWL to FOL translation that could handle that properly. But since we have value specifications already and they seem up to the task, I chose that rather than the extension.

[alanruttenberg]

#229 (comment) was written too quickly, not distinguishing the liquid from the cup. I will rewrite.

[alanruttenberg]

[Edit: mistakes: See https://github.com//issues/229#issuecomment-2113570963]

ic describes Vt because Vt has nothing to do with the liquid. It is the class of all volume qualities
that liquid held in the cup can have.

I know you said working with OWL is unnatural, but it's the only language I have. So I need to understand how you
would translate your formulation to OWL. If Vt is a class, you can't assert ic describes Vt (unless you pun, which I assume
is not your intention).

I would have to pun to write that, which is part of the reason I don't think I would bother representing Vt explicitly as a class. But FWIW I have recently had other reasons to consider punning.

In short, I am asking for agreement on how to express the following two statements in CCO:
1. Cup c is capable of holding a maximum of 1 liter of liquid.
2. Cup c holds 1/2 liter of water.

The 1/2 litre of water we will call l

Something like:
(2)
ic1 type value specification (I have asked this to be added to CCO)
ic1 has specified value .5 (ditto)
ic1 uses_measurement_unit
ic1 describes q1 (could use is_a_measurement_of since it probably is)
q1 type volume
q1 inheres_in l
l located in c

(1)
ic2 type volume capacity specification
ic2 has specified value 1
ic2 uses_measurement_unit
ic2 describes c

With volume capacity specification defined in text.

Or to have some axioms to defined volume capacity specification:

volume capacity specification subclass of capacity specification
volume capacity specification describes volume (the class, so punning)
or
volume capacity specification subclass of describes some volume (might be a lie, maybe white)

I model the temporal aspect using a time value specification and a relation 'has timestamp' e.g
t1 a time value specification
t1 has specified value

where could be an xsd:dateTimeStamp, or in my case TAI time in nanoseconds, in which case I'd also have
t1 uses_measurement_unit

Finally, associating the value specification with a time
ic1 has timestamp t1

Sorry this isn't all CCO - the value specification pattern is from OBO and I've asked for it and associated relations to be in CCO.

[alanruttenberg]

@cameronmore re: Limits relation. The thing is, what kind of thing is the subject of limits? Specifically, under what BFO class does the subject of the limits relation fall under?

A dispositional view on volume capacity would be something like: Disposition realized in trying to fill past capacity and failing, though there's a question of what the bearer is.

Back to temperature. What's 0 degrees kelvin, the minimum possible temperature? A subclass of temperature. With the BFO view of types as values, maximums and minimums are going to be types too. It's a decent philosophical stance, but a PITA to deal with, forcing an escape to information entities.

[cameronmore]

@alanruttenberg I've been thinking about the answer to that for a few weeks and am not sure. I thought it might be a kind of specifically dependent continuant that limits the realization, like an internally grounded disruption. If the maximum is ultimately a type of temperature, then the capacity is a thing that creates that maximum and not the maximum itself, but this starts to get complicated because we would have to introduce capacity as well as all the corresponding maximums that the capacity creates and then take measurements of those, but not the maximum.

This is why I was motivated to say that capacity just was the maximum and hadn't thought about the 'limits' relation.

[swartik]

A few comments before I dig into the meat of the discussion:

1. @alanruttenberg's use of puns changes my conception of how capacities would be modeled. You can ignore some of my comments yesterday.
2. But I still want to know how to express my example in OWL.
3. I agree that values are better associated with information content entities than information bearing entities. Has the request to add Value Specification been presented as a github issue?
4. The domain of uses_measurement_unit is Information Bearing Entity. Just wanted to check whether the Value Specification request covers measurements too.

[cameronmore]

@swartik @alanruttenberg Thinking about it, I think has-capacity makes sense as an object property where:

A is capacity of B = (approximately)
Function A inheres in Artifact B such when A is realized, there is no Function which is of a greater grade than Function A.

This builds the semantics of gradation into the property, which, to be fair, is already built into other classes and properties like ‘disrupts’ and ‘inhibits’ and the increase/decrease of realizable entity classes.

Is this in the right direction?

[alanruttenberg]

Quick response: I think it is the functioning rather than the function that is graded. Also, definition as given looks almost circular. Maybe
A is capacity of B = (approximately)
Function Ax inheres in Artifact B such that the realization of Ax is a process of grade x or lower.

I think there needs to be some better wording/thinking about grading, so this is just to illustrate the form.

If function A is in general say, manufacturing of widgets at some rate then Function Ax is an instance of a subclass of function A. However it would be reasonable to create an instance of Function A and then have an ICE that gives the numeric rate, since an instance of Ax would also be an instance of A.

[cameronmore]

Yeah, there's a sense of realization (functioning) I'm building into this definition, and hence almost modal. I like the definition you gave.