Conversation
aigora-de
changed the title
- Updated ies:hasCapacity domain from Element to State - Updated ies:eachHasCapacity domain from ClassOfElement to ClassOfState - Changed range to ClassOfState for both properties - Added dcterms:identifier to eachHasCapacity - Revised all sample data files to use State-centric pattern - Updated capacity.md user guide with enhanced semantics - Enhanced property comments to explain modal semantics
|
To your point "If isDisposedTo and allHaveDispositionalClass are specialisations of rdf:type and rdfs:subClassOf respectively (as stated in IES), then you must create a class like "Aeroplane that can fly at Mach 2 in a permitted use". This class has a complicated definition: a class of aeroplane such that a member can have, in some possible world, a state of flying at Mach 2 in a permitted use." That's how extensional ontologies work. That's how properties work in IES too. Fudging this won't make it better. |
|
This is difficult to review without diagrams. Are there ODM UML models for this ? The references to usage guides (e.g. docs/user-guides/networks/) don't seem to be available in this branch or in main. Do we need additional permissions ? For other reviewers trying to navigate this, the actual paths are: https://github.com/IES-Org/ont-ies/blob/rc/v5.1.0-rc2/docs/common/user-guides/capacity.md |
|
Disposition and "capacity" are not 4D problems, it's set-theory and possible worlds. |
|
@MonkeyChap asked me to have a look at this. |
|
It seems to me the points on alignment with modal logic is at best a red-herring, but may well be erroneously trying to fit some modal constraints into the model of a single world thereby introducing world set membership constraints - which may be unfounded (as Chris points out above). It is also potentially inconsistent/incompatible with the more comprehensive modal treatment in the forthcoming ies-possibilia. Capacity, as made clear in definition and description, is about potential irrespective of whether realised - in the world being described. It is therefore inconsistent to then constrain possible worlds within the definition of particular classes. There are possible worlds where a euro-fighter does not have the mach-2 capacity, there are possible worlds where it does but exercised, there are worlds where the capacity is realised at different stages in its lifetime. The modal uncertainty is which of these worlds this euro-fighter is in - not what its counterpart set is. As a state of an entity is part of the whole-life entity, a state of have a capacity implies that the thing the state is part of, has that capacity bounded by that part. Is it not the case that capacity would be better considered via the replaceable part pattern, where the replaceable part is drawn from a set of states that can fulfil the slot? Eg a state of flying at mach 2 is in the set of operational states that can be part of the euro-fighter's life. As remarked above, disposition and capacity realisation imply sets and possible worlds - possible worlds are not a 4D problem (indeed the worlds we are considering are all 4D wholes). Agree with others - UML diagrams would help reviewing |
|
Containment WRT: “An Element can contain one or more other Elements. An Element that contains, or is intended to contain, is a Container. An Element that is contained is a Contained.” WRT: “A Containment is an Element that has as parts: |
|
Flow It seems to me that something can only be in flow, i.e. motion, with respect to / relative to something else. Flow inherently involves some other element(s) in relation. Flow should therefore be considered an event involving the participation of what is flowing and what it is flowing through/across (the latter inherently involving the elements the boundary delimits). The logic of events subsuming sub-events and being part of larger event sets. then naturally follows Link measuring flows However an intermediate Node along a Link is not necessarily part of it. Therefore there is a choice: either regard an arbitrary boundary as something other than a Node, or as a special type of Node." This can get deep very quickly! Arguably the (arbitrary) boundary/node at which flow is measured - a "probe" - is not part (or at least intended to be part) of the network being measured, but is necessarily part of the physical medium over which the flow occurs. (This bring to mind the issue in quantum physics where the question arises as to whether you can measure something without affecting it...) As the position of observation strictly is part of the network at the time and location of the observation (it is in a state of being observed) but (hopefully) not affecting flow, this would favour the creation of different class of node. Out of scope here, but this leads on to what perhaps requires a more fundamental modelling connecting observer and observation to what is being observed. |
|
@nigel81562 - #17 (comment) - Uncanny. I was going to make the same point. "It seems to me that something can only be in flow, i.e. motion, with respect to / relative to something else." This shows in the Wikipedia entry as - see https://en.wikipedia.org/wiki/Lagrangian_and_Eulerian_specification_of_the_flow_field --- "The Eulerian specification of the flow field is a way of looking at fluid motion that focuses on specific locations in the space through which the fluid flows as time passes." and "The Lagrangian and Eulerian specifications of the flow field are sometimes loosely denoted as the Lagrangian and Eulerian frame of reference. However, in general both the Lagrangian and Eulerian specification of the flow field can be applied in any observer's frame of reference, and in any coordinate system used within the chosen frame of reference. " What is interesting here, is that the so-called observer's frame of reference is often another object. This seems to play directly into the 4D framework for general relativity - with reference frames for objects. One useful way of thinking about this - that originates with Robb is rapidity - https://en.wikipedia.org/wiki/Rapidity. Robb and subsequent work starts in the metric space, but it is feasible to work in the mereotopological/conformal space (if you have the causal relation). |
|
Firstly, can I say the UML diagrams were very useful. Looking at them and the rest of the text, it seems to me that the mereotopology of the proposal is not always clearly worked out. Given that the extensionality of identity is built on top of mereology, this is worth investing in. https://github.com/IES-Org/ont-ies/blob/rc/v5.1.0-rc2/docs/common/user-guides/networks/network.md Does this imply that a network is the fusion of its nodes and links? Or at a minimum has them as parts. The later UML uses an isPartOf relation, so the second option looks to be true, though I cannot see this stated directly anywhere in the model. Be good to say it, if that is intended. Does the hasEnd relation imply any mereotopology? So, is there, for example, some overlap or connection between nodes and links. The Node and Link classes presumably have instances. What characterises those instances. Can any element be a node or a link? The Highway network diagrams are ambiguous, it looks as if their nodes and links have been simplified to points and lines. I'm guessing that it is the junctions and roads that are nodes and links (as the UML suggests), that the simplification is for ease of representation. Do nodes and links have to be self-connected? Does there have to be a path from node to node along the link? Does this path have to exist at all times or just most the time? In Figure 1 - Network in IES, has End is between Nodes and links. In Figure 5 - Record of changes to a network is is also between states of Nodes. It is not clear whether these states are also members of the Nodes class. This is a good example as it shows the time sensitivity of the node-part relation. I also wonder about the mereotopology of flows. Is a flow self-connected? Traffic would seem to be a counter-example. Is there any connection between flows and nodes and links? There is a comment that "Flows can also be regarded as a Network." I wonder what work the modal 'can' is doing here. Does it mean that any flow can be regarded as a network. In other words, that instances of the class flow are also instances of the class network? Or something else? Hopefully it does not mean that one can do this if and when one wants - so the extension of the flow and network classes varies and depends upon the whim of the person encoding the data. |
|
Looking quickly at containment. https://github.com/IES-Org/ont-ies/blob/rc/v5.1.0-rc2/docs/common/user-guides/networks/containment.md #17 (comment) has this definition of Containment. Is this the only definition of Containment, etc.? I’ve only briefly looked, but it seems like you are relying on an informal grasp of the meaning (a kind of https://en.wikipedia.org/wiki/I_know_it_when_I_see_it ) rather than a definition - but maybe I have missed something.
It would be good to understand what containment implies – in the sense that neutrinos aren’t contained in the quote above. (Also, aren’t some neutrinos contained - https://en.wikipedia.org/wiki/Super-Kamiokande ?) Also, if the water flowing in an open gutter, is the water contained? If so, how is this explained – in terms of gravity and ability to flow? At the extreme, tanks and vessels have openings: in what cases do these openings count as breaching containment and where don’t they? If I turn the tank/vessel upside down and the contents flow out, are the contents still contained while they are still inside. More generally, the contained does not seem to reliably be strictly an interior, so how is this handled? By a convex hull, for example? If a convex hull, how would a meniscus be handled? (Or ice cream in a cone, or coal in a truck?) I’m guessing that when https://ifc43-docs.standards.buildingsmart.org/IFC/RELEASE/IFC4x3/HTML/lexical/IfcSpace.htm says “A space represents an area or volume bounded actually or theoretically.” The theoretically is hinting at the openings. |
|
Containment Further to Chris's comments: In general a containment may rely not just on the container, but an environmental factor; for example gravity of a very large body (the Earth say) preventing water from leaving a bucket in an upright position in said gravitational field: turn the bucket upside down and the water is no longer contained (given an open bucket). The point here is that containment is not solely reliant on the container and the thing being contained. It is not, therefore an intrinsic state of an element. The example given has L-101 during delivery D-101, the pallet loaded as a contained state (in relation to corresponding state of container SC-101). However, should the delivery include a time when the pallet fell out of container, the containment during delivery would be discontinuous. There is a temporal continuity assumption in this model, and elements are considered from external 4D perspective. The containment factors other than the container and the contained are not accounted for - thus the apparent lack of distinction between inLocation and contained remarked upon in previous comments. What should be apparent from this is that rather than being a joint part-of relationship between container and the contained, a containment should be viewed as an Event. (The pre-amble explanation given almost realises this in noting any member can be an Event, but misses that an Event can be part of a more extensive Event). Also note that IES extension guidelines state that one should Not extend Element. Given a containment event, one would have participatory states - so the state of the pallet in containment, the state of the shipping container in the containment, where the pallet is located within, and constrained to be so by the environment, the container. The environment, and relevant parts thereof, are also participants (whether explicitly called out or not). Modelling as an event also allows for further distinctions and characterisations to be made, such as 'leaky containment'... and allow for dependencies to be accommodated (must be participatory to event for the event to be). |
|
This pull request is "suspended" until a plan for addressing the issues raised is made and resources assigned. |
4 participants
This pull request is "suspended" until a plan for addressing the issues raised is made and resources assigned.
IES Common v5.1.0 Release
Summary
This release introduces two independent extensions to the IES Common ontology:
These patterns are independent and can be reviewed separately.
Part 1: Networks, Connections, Containment & Flows
New Ontology Concepts
Networks & Topology
hasEndhasStart/hasFinishisSeriesPartOfisParallelPartOfConnections
Containment
Flows
isStartBoundaryOf/isFinishBoundaryOfDocumentation (Part 1)
[User guides] (docs/common/user-guides/networks/:
inLocationfrom ContainmentWorked examples:
[Sample TTL files] (https://github.com/IES-Org/ont-ies/tree/rc/v5.1.0-rc2/docs/common/examples/sample-data):
Glossary updates with all new terms
Design Notes (Part 1)
Part 2: Capacity Pattern
Why Capacity?
The existing
ies:Capabilitypattern (viaDispositionalClassandisDisposedToas a sub-property ofrdf:type) admits two possible interpretations:Interpretation 1: The class has a complicated definition
If
isDisposedToandallHaveDispositionalClassare specialisations ofrdf:typeandrdfs:subClassOfrespectively (as stated in IES), then you must create a class like "Aeroplane that can fly at Mach 2 in a permitted use". This class has a complicated definition: a class of aeroplane such that a member can have, in some possible world, a state of flying at Mach 2 in a permitted use.This complicated class definition is derived from a much simpler concept — the
ClassOfState"Fly at Mach 2 in a permitted use" — which has a straightforward definition.Interpretation 2: The relationships are complicated
Alternatively, the intention may be to relate the class "Eurofighter" or the individual "Eurofighter XYZ-123" directly to the
ClassOfState"Fly at Mach 2 in a permitted use", which has a straightforward definition. In this case, the relationshipsisDisposedToandallHaveDispositionalClassthemselves become complicated.The Capacity pattern adopts Interpretation 2
Rather than creating intermediate classes with complicated definitions, the Capacity pattern introduces new relationships that directly relate States to ClassOfStates with straightforward definitions. This provides better 4D ontological coherence by attaching capacities to temporal parts (States) rather than whole-life Entities.
The Four Cases
Capacities and roles can be understood through a 2×2 matrix of individual vs class, for both the thing that has the capacity and the capacity itself:
Each case requires a relationship pair (relationship and its inverse):
ies:isStateOfhasRole(not yet defined)canBeAStateOfcanBeAStateOfAMemberOfeachCanHaveRoleeachCanBeAStateOfCoverage:
ies:InstalledState,ies:EventParticipantviaies:isStateOf), though no inversehasRoleis currently defined.hasCapacityandeachHasCapacity.canBeAStateOfAMemberOf/eachCanHaveRolerelationship pair.Advantages of Capacity
In addition to avoiding complicated class definitions, the Capacity pattern provides:
hasCapacity) vs actualising it (rdf:type)New Ontology Concepts (Part 2)
hasCapacityeachHasCapacityProperty Signatures:
ies:hasCapacity rdfs:domain ies:State ; rdfs:range ies:ClassOfState . ies:eachHasCapacity rdfs:domain ies:ClassOfState ; rdfs:range ies:ClassOfState .hasCapacity vs eachHasCapacity
hasCapacityeachHasCapacityWhole-Life Capacities
For capacities that persist throughout an Entity's existence, IES provides a convenient pattern: Entity subclasses are also subclasses of their corresponding State subclass (e.g.,
ies:Person rdfs:subClassOf ies:PersonState,ies:Location rdfs:subClassOf ies:LocationState).This means instances of Entity subclasses are automatically both an Entity and a State representing their whole life:
For temporal capacities (capacities during specific periods), you create explicit State instances with temporal bounds.
Backwards Compatibility
The existing patterns using
DispositionalClass,Capability, andTendencyremain fully valid. The new Capacity pattern is additive and non-breaking — implementers may choose whichever approach better fits their data and use cases.Documentation (Part 2)
[User guide] (https://github.com/IES-Org/ont-ies/blob/rc/v5.1.0-rc2/docs/common/user-guides/capacity.md) covering:
Worked example in
docs/common/examples/ies-examples.md(Section 11)Sample TTL files:
Glossary updates with Capacity, hasCapacity, and eachHasCapacity entries
Use Cases
The Capacity pattern is particularly suited for:
Other Changes
Review Notes
Feedback is requested on this Release Candidate, which introduces:
Please also flag any: