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 https://github.com/CommonCoreOntology/CommonCoreOntologies/issues/229#issuecomment-2037318665, 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...

[swartik]

@cameronmore, in your revised definition, have you thought about how you would express "is the magnitude of a disposition"? Is it as simple as one SDC specifically depending on another, or does it need to be expressed using a process and participants? To put it another way: can the characteristics of an independent continuant's disposition change, or does the independent continuant have a new and distinct disposition? For instance, what happens to storage capacity when a cave-in reduces the volume of a cave?

[cameronmore]

@swartik I'm thinking that the function already has realizable conditions encoded in the definition/axioms/queries, so linking it to that function is sufficient, we don't need to go all the way to a process in most cases.

Regarding the changing of the capacity, that is some new semantics that have to be worked out, but I think the design is straight forward. A process needs to occur to change the capacity of an entity--a facility is expanded, or a computer network has more servers added, and so on. The use-cases I have in mind for applications revolve around comparing the capacity to the current performance of a function--this room has a limit of 15 people and I'm using a recurring sparql query to check if the room is at capacity and alert on a count that approaches that limit.

I think capacities are always linked to existing (positive) dispositions and functions, capacity is an enhancement to the way we understand the realization of those dispositions and functions.

Perhaps this is because of ambiguity in natural language, but I can say that 'the cave has a storage capacity', and 'the storage function has a capacity', so I'm not settled on what the capacity s-depends on, though I'm leaning on the former and asserting a new relation between the capacity and function.

[cameronmore]

I've done a lot of thinking and it seems to me that capacities are SDCs which are the maximal realization of dispositions.

Dispositions are realized when some triggering stimulus reaches a material disposition which bears the disposition, and the disposition causes a change in some state of affairs (the process that dispositions are realized in).

Capacities describe the maximal realization of a disposition when given maximal stimulus, and thus produce maximal resulting change. For example, the disposition of a glass to hold a certain volume of water is realized when water fills the glass, and the realization of the disposition is such that water is now located inside the glass. Only when a maximal amount of water is present does a glass reach its capacity (and perhaps overflow if the stimulus is too great). There may be lots of things, like metaphysical masks, that change the context and may decrease the ability for a stimulus to reach a disposition, but there is a capacity regardless. See this paper on blindness for a similar account.

I think this interpretation is generalizable to the sorts of dispositions I want to cover with this term capacity. I'm not certain whether it is (1) a 'part' or (2) it itself 'specifically depends on' or (3) 'is boundary of' dispositions. To say that a capacity is a part of a disposition implies that it itself is a realizable, and this might make sense if we understand capacity as that maximal portion of the disposition. But, if we separate the realizable from its realization, then the parthood relation doesn't make sense. I would rather create a new 'boundary' kind of relation for the realization such that a capacity is a boundary for the realization of a disposition.

[jonathanvajda]

capacities are SDCs which are the maximal realization of dispositions.

All maximal realizations are occurrents. No SDCs are occurrents. Thus, no SDCs are maximal realizations.

But it definitely has to do with the inherent entities that capture the modality of realizations, at which point realizations would be dysfunctional, less likely, or otherwise would no longer occur. For example, suppose you have a 1-liter bottle. Pouring a half-liter of water into a receptacle is easy when the receptacle is empty, harder when it's 1/4 full, a lot harder when it is 7/16ths full, etc. There's an asymptote-like approach toward the "cannot hold another half-liter" based on how much of the capacity has already been realized. Mutatis mutandis when you are just adding a droplet of water, or a stream of droplets across a longer period of time.

Capacities describe the maximal realization of a disposition when given maximal stimulus

This is a little off. Capacities are not ICEs. So, no capacities describe.

The stimulus talk is helpful for framing this more ways we need to be able to capture. But it seems odd in some cases. It is helpful when we are talking about some disposition to react, such as when you poke a bear it growls, or when you move in front of a motion sensor it triggers a flood light to turn on. A water receptacle doesn't change when water is put in its internal material boundary. The water seems like a better candidate for "doing" anything (it is being poured). What is the stimulus? Water? What is the reaction to the stimulus? Not doing something? Worth thinking through.

See this paper on blindness for a similar account.

Lacks or privations are I think critical here, especially for artifacts and what capacities are realized (or not) and under what conditions.

I'm not certain whether it is (1) a 'part' or (2) it itself 'specifically depends on' or (3) 'is boundary of' dispositions. To say that a capacity is a part of a disposition implies that it itself is a realizable, and this might make sense if we understand capacity as that maximal portion of the disposition. But, if we separate the realizable from its realization, then the parthood relation doesn't make sense. I would rather create a new 'boundary' kind of relation for the realization such that a capacity is a boundary for the realization of a disposition.

What might be helpful here is just to describe qualities that ground the disposition, and some qualities are stronger or more exemplified than others. My muscle mass in my biceps partially ground the ability to play drums; your muscle mass in your biceps partially ground your ability to play drums. I play drums better than you, and this is grounded in the differences in qualities. When I play at my upper-bound, that limit is explained by the qualities I have; when you play at your upper-bound, that limit is explained by the qualities you have. The differences in limits between us, then, gets explained by differences in qualities that inhere in our respective bicep muscle groups.

What is the relation between the quality of muscle aggregate and the process-that-would-occur-if-at-upper-bound? That still sounds a little elusive. But think we're on the right track of talking about what SDCs are relevant, and whether they are actualized SDCs or realizable SDCs.

[cameronmore]

I have in mind two use-cases that exemplify the range of capacities I want to talk about. First, the water. The glass has a disposition 'to hold water'. A manifestation of this disposition would be a state of affairs in which water is being held. So, when the 1 liter glass holds 1 liter of water, it is no longer able to instantiate new manifestations, namely, more water being held in the glass. The glass does not break or anything like that.

But I like the idea of 'how easy is it to manifest such and such with this stimulus'. It's easy for a bodybuilder to pick up 5 pounds, but it's hard when they're already holding 250...

The second use case I have in mind is an aircraft hull's disposition to pressurize (ignoring for a moment that this is a complex disposition, with lots of other artifacts helping, just think about the skin, hull, fuselage). What happens when it reaches its asymptotic capacity? The hull cracks and the disposition is lost. Another thing to worry about down the line is gradations of failure, at what point would we say a disposition is lost, but that's often a granularity issue.

So, this is helping us along, thinking about the things that ground the disposition being important for the disposition's capacity. @APCox has thought a lot about this, and perhaps capacity is itself a realizable.

That direction got me thinking about internally grounded finks and masks (rather than external ones). But again, what 'grounds' these internal ones?

My initial thoughts about grounding go in the direction of 'dispositions inhere in material entities, and since all material entities are finite, all dispositions are finite, and further if realization occurs when stimuli trigger dispositions (and both of which are material), then baked in to the notion of realization is an idea that realization is determined by the finitude of the material entities involved.'... need to think about it more, but just sharing some thoughts.

[alanruttenberg]

This is an analysis by analogy to our understanding of temperature. Some entities have a total order on their subtypes, by which I mean there is some ordering (an example would be "greater than" or "hotter than") between instances and perhaps between types. In the case of temperature, the value of temperature represents its type (see Figure 3, [https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3718480/](Classifying Processes: An Essay In Applied Ontology)). In that paper such classes are called determinable. I think the determinable thing has some complications so just think about temperature and it's ordering. A greater-than relation hold between instances of temperature by virtue of the fact that the space of types can be totally ordered. FWIW I think that it is the types that have a greater-than relationship.

Consider a cup that can be filled with liquid. Volume of a portion of liquid is like temperature in that it has an intrinsic lower bound of 0 and no upper bound (other than to the extent that there is a finite amount of material in the universe). The volume of a portion of water than can occupy a specific cup, however, does have an upper bound. Going by analogy to temperature, call that type Vt. Consider the class of volume types which include all volume qualities whose instances are which are not greater-than Vt. The cup has the capacity to hold volumes of water that are of this type.

In the case of temperatures, numeric values of temperature are information entities that are effectively names for the different temperature types. By analogy that maximum volume is also named by some information entity. So, a cup's capacity to hold liquid is a type Vt, and a name for it is an information entity like the volume measured in cubic centimeters.

We might represent this as a relation to a type (has-capacity cup Vt). [This might be time-indexed]. A first pass representation of the capacity of a cup that can carry 1 litre is, where cup is understood to have a site that's part.

cup has-capacity Vt Vt is-a volume quality (i.e. a type, not a particular) (every) Vt inheres in some liquid that located-in cup site ic instance-of value specification ic has-value 1 ic has-unit litre ic describes Vt We could write, approximately, and ignoring time for the moment.

(iff (has-capacity cup Vt)
   (forall (l v)
      (implies
        (and 
             (instance-of l liquid)
             (located-in l cup-site)
             (inheres-in v l)
             (instance-of v volume))
          (instance-of v Vt))))

cup, cup-site, v, l are particulars liquid, volume, Vt are classes, with Vt identified with "the capacity"

But working with types like this is unnatural for OWL and because is about is promiscuous, something about a volume of liquid in a cup is about a cup as well, in which case we might just have a capacity specification that describes the cup, with the above explanation providing a path to define that kind of value specification.

[cameronmore]

I think this representation gets at the problem nicely. Would we have a generic top class 'capacity' which would have Vt under it along with the others? Or is there a 'volume capacity' defined class? (Volume in CCO is an alt label for Three Dimensional Extent, which is a Size Quality, which is a Quality).

[alanruttenberg]

Capacity in the sense I wrote isn't a class, it's more like a category whose members are classes, at the same level as the term universal. The set of volume capacities is a set of subclasses of volumes that inhere in things that have volume qualities. A specific capacity is a class (like Vt). So at least the way I've laid it out the ultimate representation would not to be to have a capacity class (Vt) but rather a capacity value specification, an information content entity. It might be said to be about some volume that inheres in a cup, though "cup" in that sentence might be a class of cups, or a particular cups, in which case punning would be used in OWL. A subclass of capacity value specification could be volume capacity specification, which we could just say is about some volume.

I started to do an analysis of the car range example, but I think that introduces some other issues as we're dealing with dispositions and realizations. I'll try to write something up about it in time.

[swartik]

@alanruttenberg Can you clarify something? In:

   (instance-of l liquid)
   (located-in l cup-site)

does this say anything about the volume of l? The located-in property assertion doesn't imply l completely occupies cup-site. If l is a drop of liquid, ic describes Vt should not hold. Do you need a more specific subproperty? Or should v also be described by a value specification?

On a side note, (inheres-in v l) makes liquids independent continuants. Hydrogen is an independent continuant, but its state (solid, liquid, gas) depends on its energy. If fuel cells ever become practical and we have to start worrying about hydrogen storage, state will have to be treated as a specifically dependent continuant.

[cameronmore]

@swartik hopefully implicit in the 'has-capacity' relation still is what I mentioned earlier about the maximal realization of a disposition, so that's doing the work, but the implied statements are not the exhaustive definition of what 'has-capacity' means, but they seem to be necessary parts of the phenomenon of capacity. Am I getting that right @alanruttenberg ?

Re capacity not being a class, that makes sense, but I would worry about having 'capacity' classes all over the hierarchy instead of all the capacities in one place.

[alanruttenberg]

@alanruttenberg Can you clarify something? In:

   (instance-of l liquid)
   (located-in l cup-site)

@swartik located-in is a lower bound. So if you x is located in y then x is not located in a proper part of y. But if y is part of z, x is also located in z.

does this say anything about the volume of l? The located-in property assertion doesn't imply l completely occupies cup-site.

No, it doesn't say anything about the volume of the liquid, which is why we have v, the volume quality that inheres in the liquid. We could separately have another volume quantity that inheres in the cup site. I didn't identify capacity with that as a) The cup site has a vague boundary and b) there could be a hole in the side of the cup.

If l is a drop of liquid, ic describes Vt should not hold. Do you need a more specific subproperty? Or should v also be described by a value specification?

v could also be specified by a value specification. 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.

On a side note, (inheres-in v l) makes liquids independent continuants. Hydrogen is an independent continuant, but its state (solid, liquid, gas) depends on its energy. If fuel cells ever become practical and we have to start worrying about hydrogen storage, state will have to be treated as a specifically dependent continuant.

Liquids, hydrogen, solids, liquids, and gases are all independent continuants. They are all material entities. The changing states of matter is a known problem of identity. Namely if you have a portion of ice in a cup and it melts yielding a portion of water in a cup is the portion of water the same particular as the portion of ice? I don't think there is an objective answer to this question and it is a matter of ontological commitment. There are some times when identity makes sense to be tracked across states and some times when it doesn't.

Regarding state, that's relevant if the choice is that the ice and water are the same particular, since then we would have to have something that changes. The state of matter would be a quality I expect.

[alanruttenberg]

@swartik hopefully implicit in the 'has-capacity' relation still is what I mentioned earlier about the maximal realization of a disposition, so that's doing the work, but the implied statements are not the exhaustive definition of what 'has-capacity' means, but they seem to be necessary parts of the phenomenon of capacity. Am I getting that right @alanruttenberg ?

That's what has-capacity means. What we call the capacity I am identifying with the superclass of all classes of volume of things located in the cup-site.

Re capacity not being a class, that makes sense, but I would worry about having 'capacity' classes all over the hierarchy instead of all the capacities in one place.

From an engineering point of view this is an issue. There is choice as to whether those classes are represented or not, or whether just the information content entity is, which is where I lean. But there's also a matter of language. Suppose we have a type of aircraft (say 747) and we had a class "747 capacity". That name could be misleading because not all instances are the maximum capacity. 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, since if i an instance of c and c subclass d then i an instance of d - that's the logical definition of subclass.

[cameronmore]

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'.

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

[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/CommonCoreOntology/CommonCoreOntologies/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]

https://github.com/CommonCoreOntology/CommonCoreOntologies/issues/229#issuecomment-2113527170 was written too quickly, not distinguishing the liquid from the cup. I will rewrite.

[alanruttenberg]

[Edit: mistakes: See https://github.com/CommonCoreOntology/CommonCoreOntologies/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.