## Paths and Traversals

E-Mail Comments to: opencyc-doc@cyc.com
Last Update: 12/13/02
Copyright© 1996-2002. All rights reserved. See Terms of Usage.

Return to Documentation Contents
Return to Vocabulary Contents

This describes Cyc constants used to represent paths, path systems, traversals of path systems, and trajectories of moving objects. See also documents for Groups, Movement, Spatial Relations, Parts of Objects, Transportation and Geography. (See also #$List and related concepts.)

### Introduction to Paths and Path Systems

See Introduction to Paths and Traversals, a summary of how and why the path system was developed as it was. Note that trajectories (of motions), paths (pre-existing paths) and traversals (of paths) need to be handled separately.

The English word "path" is ambiguous: it can mean a trajectory ("the path of a moving object") or it could mean a path that exists in the world (a road, footpath, pipeline, air-lane, etc.). The trajectories of moving things may or may not follow paths. A section called "Trajectories of Moving Things" is toward the end of this vocabulary file.

### Kinds Of Paths

"Path" here means an existing or designated path (real or abstract), not #$Trajectory or #$Traversal.

#$Path-Generic generic paths

> A collection of things that are paths or can be considered paths. Each #$Path-Generic is either a a non-self-crossing path (see #$Path-Simple) or a cycle (see #$Path-Cyclic). A #$Path-Generic may be spatio-temporally abstract (e.g. links in Graph Theory; see #$Multigraph), spatially-located but intangible (e.g. a #$LatitudeLine might be used as a path in some system; see #$Path-Spatial and its specializations), or fully concrete (such as a road, railroad, sea-lane, cowpath, pipe, blood vessel, fiber, or wire; see #$Path-Customary and #$PathArtifact). #$Path-Generic includes anything that is used as a path in some #$PathSystem (q.v.). If a #$Path-Generic is a #$Path-Customary, then it might or might not have a specified #$PathSystem in which it is a path; if the #$Path-Generic is not a #$Path-Customary, then it can only be a path in some given #$PathSystem. For example, an orange is not a customary path, but it can be a path for ants in a specified ant path system. For any #$Path-Generic, there can be a #$Traversal (q.v.) of something moving along the entirety of that path (and a single #$Traversal can cross itself, double back along itself, or go back and forth along some part of a #$Path-Generic any number of times.) Note that #$Path-Generic is _not_ a subcollection of #$Individual, because there is nothing in principle to prevent a mathematical set or a collection from being used as a path in some path system. For similar reasons, few if any (non-empty) collections or sets can definitively be considered disjoint with #$Path-Generic.
> guid: c110820b-9c29-11b1-9dad-c379636f7270
> direct instance of: #$Collection
> direct specialization of: #$Thing
> direct generalization of: #$Path-Spatial #$Path-Cyclic #$SimpleSegmentOfPath #$Path-Simple

#$Path-Simple paths that is not a loop

> An instance of #$Collection, and a specialization of #$Path-Generic. Each instance of #$Path-Simple is a path with two distinct ends that do not overlap each other (in the case of spatial paths, the two ends are spatially disjoint). Since no instance of #$Path-Simple has ends that join at one point, #$Path-Simple is disjoint with #$Path-Cyclic. Although instances of #$Path-Simple have distinct ends, some instances may have more than two things that are its end-points . For example, a path between Austin and Pittsburgh can also be a path between Texas and Pennsylvania. Notable specializations of #$Path-Simple include #$Pipe-GenericConduit, #$Nerve, and #$Stream.
> guid: bd588e69-9c29-11b1-9dad-c379636f7270
> direct instance of: #$Collection
> direct specialization of: #$Path-Generic
> direct generalization of: #$Highway #$GeneralizedTransfer #$Portal #$CordlikeObject #$EdgeOnObject-Generic #$FlowPath

#$Path-Cyclic cyclic paths **COMMENT NOT REVIEWED** **GAFs NOT REVIEWED**

> The collection of all cyclic paths, i.e. paths that form cycles, circles, loops or circuits. An instance of #$Path-Cyclic is a #$Path-Generic that can be described as a cycle, i.e., a thing like a #$Path-Simple except that the ends of the path join at one point. A #$Path-Cyclic cannot cross itself (as in a figure-eight) nor double back along itself. More formally, let PATH1 and PATH2 be two #$Path-Simples. Suppose that each end-point of PATH1 is an end point of PATH2 and vice versa, and for each X, X is a point on both PATH1 and PATH2 only if X is an end point of both paths. Then PATH1 and PATH2 together form a #$Path-Cyclic. We allow 'loops'; a loop is a cycle with only one point on it, looping from the point right back to itself. Each loop of a path system is a special instance of #$Path-Cyclic. For differences between a cycle and a loop in the same #$PathSystem, see #$loopInSystem and #$cycleInSystem.
> guid: bfa3129f-9c29-11b1-9dad-c379636f7270
> direct instance of: #$Collection
> direct specialization of: #$Path-Generic

#$Path-Spatial physical paths **COMMENT NOT REVIEWED** **GAFs NOT REVIEWED**

> A specialization of both #$Path-Generic and #$SpatialThing-Localized. Each instance of #$Path-Spatial is a path that has spatial extent, and that joins spatially located things. So instances of #$Path-Spatial include roads, corridors, wires, blood vessels, and nerves; however, purely abstract paths, such as those in kinship diagrams and mathematics, are _not_ instances of #$Path-Spatial. Instances of #$Path-Spatial may be pre-existing paths in a #$CustomarySystemOfLinks (q.v.) or they may be paths in some specially specified #$PathSystem (q.v.) consisting of spatial paths.
> guid: c095e890-9c29-11b1-9dad-c379636f7270
> direct instance of: #$FirstOrderCollection
> direct specialization of: #$SomethingExisting #$Path-Generic #$SpatialThing-Localized
> direct generalization of: #$Portal #$SolidSurfacePathThroughAir #$Path-Customary #$EdgeOnObject

#$Path-Customary routes **COMMENT NOT REVIEWED** **GAFs NOT REVIEWED**

> A specialization of #$Path-Spatial. Each instance of #$Path-Customary is a spatial path which was either designed as a path by some intelligent agent, or which has a significant known function as a path for movement. Examples include roads, railroads, sea-lanes, cowpaths, boardwalks, tubes, channels, blood vessels, fibers, wires, and communication links. An instance of #$Path-Customary may be either an instance of #$Path-Simple (in which case it would be a path with two distinct ends, not forming a cycle) or an instance of #$Path-Cyclic.
> guid: bee87cc9-9c29-11b1-9dad-c379636f7270
> direct instance of: #$ExistingObjectType
> direct specialization of: #$Path-Spatial
> direct generalization of: #$CordlikeObject #$FlowPath #$PathArtifact

#$PathArtifact constructed routes

> A specialization of both #$ConstructionArtifact and #$Path-Customary. Each instance of #$PathArtifact is a spatial path made by humans or animals. Instances of #$PathArtifact include #$ErieCanal, #$WellandShipCanal, #$ChampsElysee, #$WallStreet, and #$Highway101CA. Note that each of these artifacts is a single, particular path; to refer to a whole system of #$PathArtifacts, use #$PathArtifactSystem.
> guid: bd588ea2-9c29-11b1-9dad-c379636f7270
> direct instance of: #$ExistingObjectType
> direct specialization of: #$ConstructionArtifact #$Path-Customary
> direct generalization of: #$PathForWheeledVehicles

For specific examples, see below. Some predicates and functions assume that a particular #$PathSystem is specified, and take the #$PathSystem as an argument (their names end in "InSystem"). Others don't assume this.

### Physical Transport Path Types

These are not #$Trajectories of motions as listed above, but are pre-existing paths that a motion may (or may not) follow.

#$WaterSurfacePath water routes **COMMENT NOT REVIEWED** **GAFs NOT REVIEWED**

> The collection of pre-designated or customary #$Path-Spatials that lie along water surfaces. A moving object following (or blocking) this path is supported by the water, but is neither fully immersed in the water nor completely in the air. This collection includes sea-lanes, channels, pre-designated ship routes, safe-passage mine-free paths, etc. They may or may not be marked with #$Buoys. Certain bodies of water like #$Canals are generally #$WaterSurfacePaths or have #$WaterSurfacePaths on them. For the pure #$Trajectory of the motion of any object on a water surface, use #$WaterSurfaceTrajectory.
> guid: c0fd5053-9c29-11b1-9dad-c379636f7270
> direct instance of: #$PathType #$ExistingObjectType
> direct specialization of: #$Water #$Path-Customary #$Path-Simple

#$PathThroughWater water pathways **COMMENT NOT REVIEWED** **GAFs NOT REVIEWED**

> The collection of all designated or customary #$Path-Spatials that go entirely through water (underwater). This would include designated undersea lanes for submarines, or corridors of fish migrations, etc. An object following such a path is immersed in, and supported by, the water. Thus it excludes a #$SolidSurfacePathThroughWater, and a #$WaterSurfacePath. For arbitrary trajectories of motions through water, use #$TrajectoryThroughWater.
> guid: bd58cb07-9c29-11b1-9dad-c379636f7270
> direct instance of: #$PathType
> direct specialization of: #$Path-Spatial

#$PathThroughAir air pathways **COMMENT NOT REVIEWED** **GAFs NOT REVIEWED**

> A designated or pre-defined #$Path-Spatial all of which passes through air (mid-air). This includes air lanes, designated air navigation routes, etc. An object following this #$Path-Generic is immersed in, and supported by, if anything, the air. Thus it excludes a #$SolidSurfacePathThroughAir, a #$PathThroughAirHangingFromSolid, and a #$WaterSurfacePath. For general trajectories of moving objects through air, use #$TrajectoryThroughAir.
> guid: bd58cac5-9c29-11b1-9dad-c379636f7270
> direct instance of: #$PathType
> direct specialization of: #$Path-Spatial

#$PathThroughSolid paths through solid **COMMENT NOT REVIEWED** **GAFs NOT REVIEWED**

> The collection of all existing or designated #$Path-Spatials through solid material. Designated paths for drilling and machining are examples, as are the paths of tunnel digging and animal burrowings. Boring into wood and burrowing through the earth are locomotions which may follow paths of this type. For the pure #$Trajectory of a motion through a solid (not a designated or pre-existing path), use #$TrajectoryThroughSolid.
> guid: c0fd62b2-9c29-11b1-9dad-c379636f7270
> direct instance of: #$PathType
> direct specialization of: #$Path-Spatial

#$SolidSurfacePathThroughAir solid-surface paths through air **COMMENT NOT REVIEWED** **GAFs NOT REVIEWED**

> The collection of all existing or designated #$Path-Spatials that pass through air along a solid surface. An object following such a path is immersed in the air but supported by the solid surface of the path. To refer to a pure trajectory of the motion, regardless of whether there is any pre-existing or pre-designated #$Path-Spatial, see #$SolidSurfaceTrajectoryThroughAir.
> guid: bd58ca42-9c29-11b1-9dad-c379636f7270
> direct instance of: #$PathType
> direct specialization of: #$PartiallyTangible #$Path-Spatial
> direct generalization of: #$PathForWheeledVehicles

#$SolidSurfacePathThroughWater solid-surface paths through water **COMMENT NOT REVIEWED** **GAFs NOT REVIEWED**

> The collection of all existing or designated #$Path-Spatials through #$Water that are situated along solid surfaces. An object following such a path is immersed in the water but supported by the solid surface. For the pure #$Trajectory of any #$objectMoving through water along a solid surface, use #$SolidSurfaceTrajectoryThroughWater.
> guid: bd58ca83-9c29-11b1-9dad-c379636f7270
> direct instance of: #$PathType
> direct specialization of: #$Path-Spatial

#$AirPathThroughSolid air paths through solid **COMMENT NOT REVIEWED** **GAFs NOT REVIEWED**

> A collection of paths; a subset of #$PathThroughSolid. Each element of #$AirPathThroughSolid is a region of open space extending from at least one portal on the surface of a solid, into the interior. The portal may be open to surrounding air (as with a highway tunnel), or it may be covered. Some elements of #$AirPathThroughSolid go `all the way through' the solid; such paths have at least two portals. See also #$Portal, #$Cavity, #$PieceOfFreeSpace.
> guid: c0f2a4ea-9c29-11b1-9dad-c379636f7270
> direct instance of: #$PathType
> direct specialization of: #$Cavity

#$OrbitalPath orbits **COMMENT NOT REVIEWED** **GAFs NOT REVIEWED**

> The path followed by an object revolving around another object, under the influence of gravitation.
> guid: be011027-9c29-11b1-9dad-c379636f7270
> direct instance of: #$PathType
> direct specialization of: #$Path-Spatial

#$PathThroughAirHangingFromSolid paths through air involving hanging from a solid **COMMENT NOT REVIEWED** **GAFs NOT REVIEWED**

> A #$Path-Spatial through air, while hanging from a solid, such as brachiating from one tree branch to another. An object following this #$Path-Spatial is immersed in the air but supported by the solid.
> guid: c0fd5297-9c29-11b1-9dad-c379636f7270
> direct instance of: #$PathType
> direct specialization of: #$Path-Spatial

### Other Path

#$PathSystem path systems

> The collection of all specified systems of paths and links, including both tangible path systems (such as the system of streets in a city) and abstract path systems (such as a multigraph). Each instance of #$PathSystem consists of a nonempty set of points (where each point is an instance of #$Thing, and is related to the instance of #$PathSystem via the predicate #$pointInSystem), a set of nodes (a subset of the set of points -- each node is related to the instance of #$PathSystem via the predicate #$nodeInSystem) a set of links (where each link is an instance of #$Path-Simple, and is related to the instance of #$PathSystem via the predicate #$linkInSystem), and optionally a set of loops (where each loop is an instance of #$Path-Cyclic, and is related to the instance of #$PathSystem via the predicate #$loopInSystem). In order to specify which link is between which two nodes in the system, which point is on which link in the system, which node is on which loop in the system, and so on, see the following predicates: #$pathBetween, #$pointOnPath, #$pointOnCycle, #$betweenOnPath, #$linkBetweenInSystem, #$junctionInSystem, #$deadEndInSystem, #$isolatedNodeInSystem, and #$connectedInSystem. Notable specializations of #$PathSystem include #$Semi-DirectedPathSystem, #$Multigraph, and #$SimplePathSystem. In order to specify the subsystem relation between path systems, see the predicate #$subPathSystems.
> guid: bfd62da4-9c29-11b1-9dad-c379636f7270
> direct instance of: #$Collection
> direct specialization of: #$Thing
> direct generalization of: #$SpatialPathSystem #$PointFinitePathSystem #$Semi-DirectedPathSystem #$ConnectedPathSystem #$SimplePathSystem #$Multigraph

#$JunctionOfPaths junctions **COMMENT NOT REVIEWED** **GAFs NOT REVIEWED**

> The collection of junctions of paths, each junction being an arrangement of three or more distinct instances of #$Path-Customary such that they are all locally connected to each other by joining at the #$JunctionOfPaths. It includes the case of two or more paths that 'cross' at a junction (because four path segments are thereby joined), but not the case in which the end of one path simply joins the end of another path, and no others. For junctions in #$PathSystems, see #$junctionInSystem. (Determining what constitutes a #$JunctionOfPaths depends on the #$PathTypes of the joined paths; if it is #$River then only a junction of rivers qualifies, not the place where a road joins a river.)
> guid: c0fbbdc4-9c29-11b1-9dad-c379636f7270
> direct instance of: #$ObjectType
> direct specialization of: #$ArrangementOfLikeObjects
> direct generalization of: #$JunctionOfPipes

#$NonintrusiveJunction nonintrusive junction **COMMENT NOT REVIEWED** **GAFs NOT REVIEWED**

> The collection of junctions or crossings of #$Path-Generics in each of which: one path crosses, or its end joins the side of, another path of the same, or possibly a somewhat different, #$PathType, without so intruding upon or affecting the path as to cause it to be different in nature or name on either side of that junction. (Examples: A small side street joins a major boulevard and the boulevard does not change size or name at the junction. A hallway ends at another hall, but only allows looking through a window into it. A railroad crossing. A small vein is one of the #$sideBranches of a large vein and the name of the large vein doesn't change at that point.)
> guid: be9a14bc-9c29-11b1-9dad-c379636f7270
> direct instance of: #$RegionType
> direct specialization of: #$JunctionOfPaths

#$BranchingJunction branching junction **COMMENT NOT REVIEWED** **GAFs NOT REVIEWED**

> The collection of all junctions of instances of #$Path-Customary in which one #$Path-Customary adjoining the junction #$branchesInto two or more others, the latter being about equal in size to one another and no wider than the former. Distinct from a #$SideBranchJunction in which a small #$Path-Customary joins the side of a large one.
> guid: bed90aa4-9c29-11b1-9dad-c379636f7270
> direct instance of: #$RegionType
> direct specialization of: #$JunctionOfPaths

#$SideBranchJunction side branch junction **COMMENT NOT REVIEWED** **GAFs NOT REVIEWED**

> The collection of junctions of instances of #$Path-Customary in which each junction is where a larger #$Path-Customary is joined along its side by a substantially smaller #$Path-Customary that ends there (this can be described using the predicate #$sideBranches). It is often a T-junction, but the smaller #$Path-Customary may join at any angle. This does not depend on any direction of movement or flow along the paths. In systems of named paths, it is usual for the large #$Path-Customary to keep the same name on both sides of the #$SideBranchJunction. See also the contrasting #$BranchingJunction.
> guid: be3ed1d3-9c29-11b1-9dad-c379636f7270
> direct instance of: #$RegionType
> direct specialization of: #$Individual

#$CustomarySystemOfLinks customary system of links

> A specialization of #$SpatialThing-Localized. Each instance of #$CustomarySystemOfLinks is a customary or conventional network system consisting of interconnected links (instances of #$Path-Customary) and nodes of obvious types, where the elements of the system (i.e., the points, nodes, and links of the system) can be assumed without specifying them as sets (note that this is in contrast to instances of #$PathSystem, in which the sets of point, nodes, links, and loops (if any) have to be specified for the system). Instances of #$CustomarySystemOfLinks include pipe systems, road systems, vascular systems, wiring systems, and mechanical linkages. The links of any #$CustomarySystemOfLinks are assumed to share certain characteristics. For example, in a road system, pipes are not links, nor are streetlights, road paint, or other non-roadways; only the roadways forming the road system are links in that system. Moreover, what constitutes a #$JunctionOfPaths (q.v.) or #$pathTerminus (q.v.) in the system should be obvious from the system type. The links are related to the assumed system by #$linksOfCustomarySystem (q.v.).
> guid: c0ee5ac3-9c29-11b1-9dad-c379636f7270
> direct instance of: #$ObjectType
> direct specialization of: #$SpatialThing-Localized
> direct generalization of: #$PipingSystem-Generic #$PathArtifactSystem

#$PathArtifactSystem constructed route systems

> #$PathArtifactSystem is a specialization of #$Artifact-NonAgentive, #$InanimateThing, and #$CustomarySystemOfLinks. Each instance of #$PathArtifactSystem is an artificial system consisting of several instances of #$PathArtifact (q.v.). Important specializations of #$PathArtifactSystem include #$ComputerNetwork, #$RoadSystem, and #$SewerSystem
> guid: be60aba5-9c29-11b1-9dad-c379636f7270
> direct instance of: #$ExistingObjectType
> direct specialization of: #$Artifact-NonAgentive #$InanimateThing #$CustomarySystemOfLinks
> direct generalization of: #$ComputerNetwork

### Structural Kinds Of Path Systems

#$PathSystem path systems

> The collection of all specified systems of paths and links, including both tangible path systems (such as the system of streets in a city) and abstract path systems (such as a multigraph). Each instance of #$PathSystem consists of a nonempty set of points (where each point is an instance of #$Thing, and is related to the instance of #$PathSystem via the predicate #$pointInSystem), a set of nodes (a subset of the set of points -- each node is related to the instance of #$PathSystem via the predicate #$nodeInSystem) a set of links (where each link is an instance of #$Path-Simple, and is related to the instance of #$PathSystem via the predicate #$linkInSystem), and optionally a set of loops (where each loop is an instance of #$Path-Cyclic, and is related to the instance of #$PathSystem via the predicate #$loopInSystem). In order to specify which link is between which two nodes in the system, which point is on which link in the system, which node is on which loop in the system, and so on, see the following predicates: #$pathBetween, #$pointOnPath, #$pointOnCycle, #$betweenOnPath, #$linkBetweenInSystem, #$junctionInSystem, #$deadEndInSystem, #$isolatedNodeInSystem, and #$connectedInSystem. Notable specializations of #$PathSystem include #$Semi-DirectedPathSystem, #$Multigraph, and #$SimplePathSystem. In order to specify the subsystem relation between path systems, see the predicate #$subPathSystems.
> guid: bfd62da4-9c29-11b1-9dad-c379636f7270
> direct instance of: #$Collection
> direct specialization of: #$Thing
> direct generalization of: #$SpatialPathSystem #$PointFinitePathSystem #$Semi-DirectedPathSystem #$ConnectedPathSystem #$SimplePathSystem #$Multigraph

#$PathSystemType-Structural types of path system classified by structure

> A collection of collections. Each instance of #$PathSystemType-Structural is a collection of path systems that share a certain kind of structrue. Examples include #$PointFinitePathSystem, #$NodeFinitePathSystem, #$LinkFinitePathSystem, #$FinitaryJunctionPathSystem, #$SimplePathSystem, #$Multigraph, #$FiniteMultigraph, #$SimpleGraph-GraphTheoretic, #$ConnectedPathSystem, #$Semi-DirectedPathSystem, #$DirectedPathSystem, #$BidirectedPathSystem, #$DirectedAcyclicPathSystem, #$BoundedDirectedPathSystem, #$DirectedMultigraph, #$DirectedGraph, #$DirectedAcyclicGraph, #$BoundedDirectedAcyclicGraph, and #$NetworkFlowSystem-Bounded.
> guid: befbfb9f-9c29-11b1-9dad-c379636f7270
> direct instance of: #$CollectionType
> direct specialization of: #$Collection

#$ConnectedPathSystem connected path systems

> A subcollection of #$PathSystem instances of which are connected , as opposed to being in separate pieces. For any distinct points A and B in a connected path system SYS, there is a path PATH in SYS that both A and B are on. That is, a path system SYS is an instance of #$ConnectedPathSystem if and only if, for any distinct points A and B in SYS, there is a path PATH in SYS such that (#$pathBetweenInSystem PATH A B SYS) holds. Note that according to this definition, a connected path system does not necessarily contain a link -- a path system containing a single node and no links will be a connected path system. Note also that because of the CycL treatment of paths (see #$pathInSystem) and nodes (see #$nodeInSystem), there is a path between every two points in SYS just in case there is a path between every two nodes in SYS.
> guid: bd73edb5-9c29-11b1-9dad-c379636f7270
> direct instance of: #$PathSystemType-Structural
> direct specialization of: #$PathSystem
> direct generalization of: #$ComputationalSystem #$ConnectedPhysicalPathSystem #$Tree-PathSystem

#$SimplePathSystem simple path systems **COMMENT NOT REVIEWED** **GAFs NOT REVIEWED**

> An instance of #$PathSystemType-Structural and the collection of #$PathSystems without loops or parallel links. This collection includes #$SimpleGraph-GraphTheoretic when there are no non-node points along links.
> guid: c0f34819-9c29-11b1-9dad-c379636f7270
> direct instance of: #$PathSystemType-Structural
> direct specialization of: #$PathSystem
> direct generalization of: #$Nerve #$Tree-PathSystem #$SimpleGraph-GraphTheoretic

#$Multigraph multigraphs **COMMENT NOT REVIEWED** **GAFs NOT REVIEWED**

> An instance of #$PathSystemType-Structural and a subcollection of #$PathSystem. Each instance of #$Multigraph is an instance of #$PathSystem in which the only points are nodes in the system and all paths are made of links (i.e., no intermediate points along links). Sometime such a system is called a graph or multi-graph in graph theory. A #$Multigraph consists of nodes interconnected by links, with loops on single nodes allowed, and with multiple links between the same two nodes also allowed. (For a graph with no parallel links and no loops, see #$SimpleGraph-GraphTheoretic.
> guid: bde212ef-9c29-11b1-9dad-c379636f7270
> direct instance of: #$PathSystemType-Structural #$AtemporalNecessarilyEssentialCollectionType
> direct specialization of: #$PointFinitePathSystem #$RelationalStructure
> direct generalization of: #$SimpleGraph-GraphTheoretic #$DirectedMultigraph

#$SimpleGraph-GraphTheoretic simple graphs **COMMENT NOT REVIEWED** **GAFs NOT REVIEWED**

> The collection of all #$PathSystems that are instances of both #$SimplePathSystem and #$Multigraph. Each instance of #$SimpleGraph-GraphTheoretic is a 'graph', as studied in graph theory, in which there are neither loops nor multiple links between the same pair of nodes.
> guid: be269b3d-9c29-11b1-9dad-c379636f7270
> direct instance of: #$PathSystemType-Structural #$ObjectType
> direct specialization of: #$SimplePathSystem #$Multigraph
> direct generalization of: #$DirectedGraph

#$NodeFinitePathSystem node finite path systems **COMMENT NOT REVIEWED** **GAFs NOT REVIEWED**

> The collection of all #$PathSystems each of which has finitely many nodes, i.e., the collection of every #$PathSystem SYS such that the set (#$NodesFn SYS) is finite. See also #$nodeInSystem. Note that there may still be infinitely many 'points' along the links between nodes in such a system. There could also be infinitely many links, such as between just two nodes.
> guid: c060247b-9c29-11b1-9dad-c379636f7270
> direct instance of: #$PathSystemType-Structural
> direct specialization of: #$PathSystem

#$PointFinitePathSystem point finite path systems **COMMENT NOT REVIEWED** **GAFs NOT REVIEWED**

> The collection of all #$PathSystems each of which has at most finitely many 'points' on each link, i.e., the collection of every #$PathSystem SYS such that for each link LINK in SYS, (#$TheSetOf X (#$and (#$elementOf X (#$PointsInSystemFn SYS)) (#$pointOnPath X LINK))) is finite. (See also #$pointInSystem.) Note that in #$PathSystems, 'points' may occur along links between nodes (see #$nodeInSystem), while nodes themselves are always 'points' of the system.
> guid: be35b345-9c29-11b1-9dad-c379636f7270
> direct instance of: #$PathSystemType-Structural
> direct specialization of: #$PathSystem
> direct generalization of: #$Multigraph

#$LinkFinitePathSystem link finite path systems **COMMENT NOT REVIEWED** **GAFs NOT REVIEWED**

> The collection of all #$PathSystems each of which has finitely many links, i.e., the collection of every #$PathSystem SYS such that the set (#$LinksFn SYS) is finite. See also #$linkInSystem.
> guid: bdb0062c-9c29-11b1-9dad-c379636f7270
> direct instance of: #$PathSystemType-Structural
> direct specialization of: #$PathSystem

#$FinitaryJunctionPathSystem finitary junction path systems **COMMENT NOT REVIEWED** **GAFs NOT REVIEWED**

> The collection of all #$PathSystems in which all junctions are finitary, i.e., all junctions are intersections joining only finitely many links and loops. A junction X in a #$PathSystem SYS is finitary if there are only finitely many links and loops in SYS that X is on. See #$junctionInSystem and #$finitaryJunctionInSystem.
> guid: be488a82-9c29-11b1-9dad-c379636f7270
> direct instance of: #$PathSystemType-Structural
> direct specialization of: #$PathSystem

#$FiniteMultigraph finite multigraph **COMMENT NOT REVIEWED** **GAFs NOT REVIEWED**

> The collection of all #$Multigraphs (interconnected systems of nodes and links) that have only finitely many nodes, links and loops. This is the intersection of #$Multigraph, #$NodeFinitePathSystem and #$LinkFinitePathSystem.
> guid: bea2c49a-9c29-11b1-9dad-c379636f7270
> direct instance of: #$PathSystemType-Structural #$ObjectType
> direct specialization of: #$Multigraph

#$Semi-DirectedPathSystem semi-directed path systems

> An instance of #$PathSystemType-Structural and a subcollection of #$PathSystem. Each instance of #$Semi-DirectedPathSystem is a path system SYS in which every link LINK is given at least one direction (specified by (#$linkFromToInSystem LINK X Y SYS)), and in which every loop is given two directions (so in a sense we can ignore the directions of loops). The directions of paths and non-loop-cycles (if there are any) in SYS are determined by the directions of links in SYS. When designing a particular semi-directed path system, it is convenient to create a constant for the system (say SYS1) and to assert that it is an instance of #$Semi-DirectedPathSystem (#$isa SYS1 #$Semi-DirectedPathSystem). One can then create a constant for each node (such as Node1) in the system, and a constant for each link (such as LinkA) in the system (using (#$isa LinkA #$Path-Simple), and then assert the directions of links using #$linkFromToInSystem (e.g., (#$linkFromToInSystem LinkA Node1 Node2 SYS1)). The axioms for #$linkFromToInSystem will allow one to infer other assertions, such as those involving #$pointOnPath, #$linkBetweenInSystem, #$nodeInSystem, and #$linkInSystem. One can then proceed creating loops, isolated points, and extra points on links, if they are desired.
> guid: bebe0ecc-9c29-11b1-9dad-c379636f7270
> direct instance of: #$PathSystemType-Structural
> direct specialization of: #$PathSystem
> direct generalization of: #$BidirectedPathSystem #$DirectedPathSystem

#$DirectedPathSystem directed path systems

> An instance of #$PathSystemType-Structural and a specialization of #$Semi-DirectedPathSystem. Each instance of #$DirectedPathSystem is a path system SYS in which every link LINK is given exactly one direction (specified by (#$linkFromToInSystem LINK X Y SYS), (#$PathFromFn LINK SYS), or (#$PathToFn LINK SYS)). Note that #$PathFromFn and #$PathToFn are only defined for directed path systems.
> guid: c0a745ca-9c29-11b1-9dad-c379636f7270
> direct instance of: #$PathSystemType-Structural
> direct specialization of: #$Semi-DirectedPathSystem
> direct generalization of: #$DirectedMultigraph #$DirectedAcyclicPathSystem

#$BidirectedPathSystem bidirected path systems

> An instance of #$PathSystemType-Structural and a specialization of #$Semi-DirectedPathSystem. Each instance of #$BidirectedPathSystem is such that every link in it has two directions (see #$linkFromToInSystem).
> guid: beffe753-9c29-11b1-9dad-c379636f7270
> direct instance of: #$PathSystemType-Structural
> direct specialization of: #$Semi-DirectedPathSystem

#$DirectedGraph directed graphs **COMMENT NOT REVIEWED** **GAFs NOT REVIEWED**

> The collection of all directed simple graphs, i.e., node-and-link structure in which every link has one direction and no multiple links (between a pair of nodes) or loops are allowed, as studied in graph theory. This is the intersection of #$SimpleGraph-GraphTheoretic and #$DirectedMultigraph, which is the same as the intersection of #$SimpleGraph-GraphTheoretic and #$DirectedPathSystem.
> guid: beb3df26-9c29-11b1-9dad-c379636f7270
> direct instance of: #$PathSystemType-Structural #$ObjectType
> direct specialization of: #$SimpleGraph-GraphTheoretic #$DirectedMultigraph
> direct generalization of: #$DirectedAcyclicGraph

#$DirectedMultigraph directed multigraph

> A specialization of both #$DirectedPathSystem and #$Multigraph. Each instance of #$DirectedMultigraph is a multigraph in which every link has one direction. Note that there can be loops and multiple links between a pair of nodes in a given instance of #$DirectedMultigraph.
> guid: c0ba0c32-9c29-11b1-9dad-c379636f7270
> direct instance of: #$PathSystemType-Structural #$AtemporalNecessarilyEssentialCollectionType
> direct specialization of: #$DirectedPathSystem #$Multigraph
> direct generalization of: #$DirectedAcyclicGraph #$DirectedGraph #$BayesNet

#$DirectedAcyclicPathSystem directed acyclic path systems

> The collection of all #$DirectedPathSystems each of which has no directed cycle in it (see #$directedCycleInSystem). Note that each instance of #$DirectedAcyclicPathSystem has no loops in it, although it may have an undirected graph cycle in it.
> guid: bdd9cff1-9c29-11b1-9dad-c379636f7270
> direct instance of: #$PathSystemType-Structural
> direct specialization of: #$DirectedPathSystem
> direct generalization of: #$DirectedAcyclicGraph

#$Tree-PathSystem tree path systems **COMMENT NOT REVIEWED** **GAFs NOT REVIEWED**

> The collection of all those #$ConnectedPathSystems that look like trees, i.e., those #$ConnectedPathSystems that have no #$Path-Cyclics at all. Note that since each instance of #$Tree-PathSystem has no cycles in it, it has no loops, nor multiple links between two nodes.
> guid: be70229a-9c29-11b1-9dad-c379636f7270
> direct instance of: #$PathSystemType-Structural
> direct specialization of: #$SimplePathSystem #$ConnectedPathSystem
> direct generalization of: #$Nerve

#$DirectedAcyclicGraph Directed Acyclic Graph **COMMENT NOT REVIEWED** **GAFs NOT REVIEWED**

> The collection of all those #$DirectedGraphs (node-and-link structures in which each link has one direction) each of which has no directed cycle in it. This is the intersection of #$DirectedGraph and #$DirectedAcyclicPathSystem (which is the same as the intersection of #$SimpleGraph-GraphTheoretic and #$DirectedAcyclicPathSystem). A #$DirectedAcyclicGraph is often used as a representation of a #$PartialOrdering.
> guid: bed5ca59-9c29-11b1-9dad-c379636f7270
> direct instance of: #$PathSystemType-Structural #$ObjectType
> direct specialization of: #$DirectedGraph #$DirectedAcyclicPathSystem
> direct generalization of: #$BayesNet

#$BoundedDirectedPathSystem bounded directed path systems **COMMENT NOT REVIEWED** **GAFs NOT REVIEWED**

> The collection of all those #$DirectedPathSystems each of which constains a unique node that is the source node in the system (see #$sourceNodeInSystem), and a unique node that is the sink node in the system (see #$sinkNodeInSystem).
> guid: bd5bf898-9c29-11b1-9dad-c379636f7270
> direct instance of: #$PathSystemType-Structural
> direct specialization of: #$DirectedPathSystem #$ConnectedPathSystem

#$BoundedDirectedAcyclicGraph bounded directed acyclic graph **COMMENT NOT REVIEWED** **GAFs NOT REVIEWED**

> The collection of all those #$DirectedAcyclicGraphs in each of which there is only a single source node and a single sink node. This is the intersection of #$DirectedAcyclicGraph and #$BoundedDirectedPathSystem. See #$sourceNodeInSystem and #$sinkNodeInSystem.
> guid: c0a6d152-9c29-11b1-9dad-c379636f7270
> direct instance of: #$PathSystemType-Structural #$ObjectType
> direct specialization of: #$DirectedAcyclicGraph

### Path Predicates Not Requiring A Specified Path System

#$onPath on path

> (#$onPath THING PATH) means that THING is located along (on or adjacent to) the #$Path-Generic PATH. THING could be a moving object, or it could be a stationary point (in the latter case, see the more specific predicate #$pointOnPath). For example, Saint Louis, Missouri was #$onPath U.S. Route 66, as was Missouri, any car driving along Route 66, and any lamp-post alongside it.
> guid: c10b5746-9c29-11b1-9dad-c379636f7270
> direct instance of: #$TransitiveBinaryPredicate #$IrreflexiveBinaryPredicate

#$pointOnPath-Generic point on path **COMMENT NOT REVIEWED** **GAFs NOT REVIEWED**

> (#$pointOnPath-Generic POINT PATH-GENERIC) holds just in case either (#$pointOnPath POINT PATH-GENERIC) or (#$pointOnCycle POINT PATH-GENERIC) holds. Note that (#$pointOnPath POINT PATH-GENERIC) and (#$pointOnCycle POINT PATH-GENERIC) cannot both hold, and hence (#$pointOnPath-Generic POINT PATH-GENERIC) amounts to (#$xor (#$pointOnPath POINT PATH-GENERIC) (#$pointOnCycle POINT PATH-GENERIC)).
> guid: bf3dc2f7-9c29-11b1-9dad-c379636f7270
> direct instance of: #$AsymmetricBinaryPredicate
> direct specialization of: #$onPath

#$pointOnPath point on simple path

> A specialization of the predicate #$onPath that relates a simple path (see #$Path-Simple) to any point on that path. (#$pointOnPath POINT PATH) means that POINT is a point along PATH. That is, POINT is on PATH but cannot move along PATH (even if it could move in some other sense). It might or might not be the case that POINT, or some part of it, is a part of PATH. POINT is not a subpath (see #$subPaths) of PATH; it is not something that is on PATH only occasionally (such as something moving along or stopped on PATH); and it is does not have PATH as a part (e.g. Washington DC is not a point on its own Pennsylvania Avenue). Note that the relative positions of points on a path do not in general form a linear order (see #$TotalOrdering) unless the points and the path are part of a particular #$PathSystem. For example, if no path system is specified, both Austin and Texas can be veiwed as points on Interstate 35.
> guid: c0408997-9c29-11b1-9dad-c379636f7270
> direct instance of: #$AsymmetricBinaryPredicate
> direct specialization of: #$pointOnPath-Generic

#$pointOnCycle point on cycle

> (#$pointOnCycle POINT CYCLE) means that the #$Thing POINT is a stationary point (or place) on a #$Path-Cyclic CYCLE.
> guid: c12d1757-9c29-11b1-9dad-c379636f7270
> direct instance of: #$AsymmetricBinaryPredicate
> direct specialization of: #$pointOnPath-Generic

#$adjacentPathsAtJunction path adjoining a junction **COMMENT NOT REVIEWED** **GAFs NOT REVIEWED**

> (adjacentPathsAtJunction JUNCT PATH) means that the #$JunctionOfPaths JUNCT has PATH as one of the paths (instances of #$Path-Generic) joining it. A junction may connect many paths (it must connect at least three distinct paths), and a path may pass through many junctions, and may end at a junction. Examples: all the streets meeting at a certain #$Intersection-Street, the particular #$Trachea and both primary bronchi meeting at the #$TracheobronchialJunction between a certain person's #$Lungs, and three #$LongitudeLines intersecting at the #$SouthPole. Neither PATH nor JUNCTION need be instances of #$PartiallyTangible, #$TemporalThing, or #$SpatialThing; however if PATH is, JUNCTION must also be.
> guid: bfd6e907-9c29-11b1-9dad-c379636f7270
> direct instance of: #$AsymmetricBinaryPredicate

#$betweenOnPath item between two others on some path **COMMENT NOT REVIEWED** **GAFs NOT REVIEWED**

> (#$betweenOnPath X Y Z PATH) means that X, Y and Z are points on the path PATH and X is between Y and Z. Note that this gives no ordering of Y and Z; it just claims that X is between them. Note: Given a #$Path-Customary PATH and points or places on PATH, #$betweenOnPath does not always determine a linear order (#$TotalOrdering) on the set of all points on PATH when PATH is not part of a specified #$PathSystem (since one thing on such a path -- #$onPath PATH -- may be part of another). However, in a specified #$PathSystem SYS, #$betweenOnPath does determine a linear order on the set of all points on PATH in SYS.
> guid: c0e50f87-9c29-11b1-9dad-c379636f7270
> direct instance of: #$QuaternaryPredicate

#$pathConnects path connection

> A #$CustomaryPathCycLConstant used for stating that a given path connects two things. (#$pathConnects PATH HERE THERE) means that PATH connects HERE and THERE. Often PATH is a physical path or connection along which objects or information may travel between HERE and THERE. Note that PATH might extend beyond HERE or THERE (cf. #$pathBetween). If PATH is bidirectional, then (#$pathConnects PATH THERE HERE) holds as well; but if PATH is unidirectional (see #$DirectedCustomaryPath), this does not hold; cf. the more general #$pathConnects-Commutative.
> guid: c0f2a229-9c29-11b1-9dad-c379636f7270
> direct instance of: #$TernaryPredicate

#$pathBetween path between the specified paths

> (#$pathBetween PATH X Y) means that the #$Path-Simple PATH goes between points (or places) X and Y, where X and Y do not 'overlap', and no further. Both X and Y have to be on PATH (see #$pointOnPath). Note that (#$pathBetween PATH X Y) is more specific than (#$pathConnects PATH X Y) because here the PATH cannot extend beyond X and Y. Within a particular #$PathSystem, a path's end points in the system are unique, and #$pathBetweenInSystem (q.v.) is restricted to paths and points in the system. When considered without a context of a path system, a path may have several different places at one end, such as Austin and Texas both being at the same end of some path along Highway I-35.
> guid: c065f088-9c29-11b1-9dad-c379636f7270
> direct instance of: #$TernaryPredicate
> direct specialization of: #$pathConnects

#$sideBranches side branches **COMMENT NOT REVIEWED** **GAFs NOT REVIEWED**

> (#$sideBranches MAINPATH SIDEPATH) means that the #$Path-Customary SIDEPATH ends where it joins the #$Path-Customary MAINPATH somewhere along the latter's length other than at an end. The basic nature and name of MAINPATH on either side of the junction does not change at that point; MAINPATH and SIDEPATH joined at a #$SideBranchJunction, which is a #$NonintrusiveJunction. Contrast this predicate with #$branchesInto.
> guid: bf069a35-9c29-11b1-9dad-c379636f7270
> direct instance of: #$AsymmetricBinaryPredicate #$ConnectionPredicate

#$pathTerminus path end point

> A predicate that relates a given simple customary path (see #$Path-Simple and #$Path-Customary) to its terminating ends. (#$pathTerminus PATH END) means that END is a terminating end of PATH, and that there are no further paths of the same type issuing from END that are spatially disjoint from PATH itself. A terminal end of any simple customary path may be a dead-end (i.e. a closed-off path end) or it may be open; it cannot be a #$JunctionOfPaths with more paths of the same basic type issuing beyond it. Contrast this with the predicate #$deadEndInSystem, which indicates a terminus with respect to a specified #$PathSystem only.
> guid: c10b572e-9c29-11b1-9dad-c379636f7270
> direct instance of: #$BinaryPredicate
> direct specialization of: #$endsOfPathSegment

#$linksOfCustomarySystem links of customary system **COMMENT NOT REVIEWED** **GAFs NOT REVIEWED**

> (#$linksOfCustomarySystem ASSUMEDSYSTEM LINK) means that the #$CustomarySystemOfLinks ASSUMEDSYSTEM has the individual #$SimpleSegmentOfPath LINK as one of its links (where 'link' means a path with no junctions along it). Each such link is of the path type that ASSUMEDSYSTEM is made of: a highway system is assumed to be comprised of roadways linking junctions or towns (and some dead-ends); each roadway without junctions is one of the links. The parts of a road (pavement, streetlight, stripe in middle, culverts, etc.) are not #$linksOfCustomarySystem. Similarly the #$linksOfCustomarySystem of a plumbing system are the pipes, but not the straps holding the pipes. Thus a #$CustomarySystemOfLinks may have various kinds of #$parts that are not #$linksOfCustomarySystem. Contrast this with the formal case where a specified #$PathSystem is given; in this case the predicates #$linkInSystem and #$pathInSystem are used.
> guid: be9b44d9-9c29-11b1-9dad-c379636f7270
> direct instance of: #$AsymmetricBinaryPredicate #$PartPredicate
> direct specialization of: #$parts

### Path Predicates That Require A Specified Path System

#$pointInSystem point in system

> A binary predicate that relates #$PathSystems (q.v.) to the points in those systems. (#$pointInSystem POINT SYSTEM) means that POINT is either a point on a path in, or a node in SYSTEM. Each path system has at least one point. Note that virtually any type of #$Thing can in principle serve as a point in some path-system (which is why the first argument-place of #$pointInSystem is not constrained to, e.g., instances of #$Individual). The set of all _nodes_ in a given path-system is an important subset of the set of all _points_ in that system; see #$nodeInSystem for the difference between nodes and other (i.e. non-node) points. See also #$PointsInSystemFn.
> guid: c01c8e07-9c29-11b1-9dad-c379636f7270
> direct instance of: #$AsymmetricBinaryPredicate

#$nodeInSystem node in system

> A specialization of #$pointInSystem (q.v.) that relates #$PathSystems (q.v.) to their nodes . (#$nodeInSystem NODE SYSTEM) means that NODE is a node in SYSTEM. The nodes of SYSTEM are distinguished from its other points as follows. (i) Every node in SYSTEM is a point in SYSTEM, but only nodes can be either end points of links (see #$linkBetweenInSystem), deadend points (see #$deadEndInSystem) or isolated points (i.e. points that are not on any link or loop; see #$isolatedNodeInSystem). (ii) Each point that is not a node must be somewhere on a single link. That is, for each point POINT in SYSTEM, either (#$pointOnPath POINT LINK) holds for unique link LINK in SYSTEM, or POINT is a node. Thus every intersection point (see #$junctionInSystem) in SYSTEM is a node. See also #$NodesInSystemFn.
> guid: bfbd5122-9c29-11b1-9dad-c379636f7270
> direct instance of: #$AsymmetricBinaryPredicate
> direct specialization of: #$pointInSystem

#$linkInSystem link in system

> (#$linkInSystem LINK SYS) means that LINK is an instance of #$Path-Simple taken as a primitive path (called a link) in the #$PathSystem SYS. For each link LINK in a path system SYS, there is a unique pair {X, Y} of different nodes in SYS (see #$nodeInSystem) such that X and Y are the two end-points of LINK in SYS. Other points can also be on LINK, but they cannot be nodes in SYS. There can be no point on a link that is different from its end points but nevertheless on another link; in other words, no matter how many points there are on a particular link in a path system, none of them can be an 'intersection' (see #$junctionInSystem) except the end points of the link, which are nodes in the system. Each link in SYS is also a path in SYS; that is, (#$linkInSystem LINK SYS) implies (#$pathInSystem LINK SYS). Note that there is no general collection of all links. Any path can be a link if you can somehow ignore the intersection points on it -- it all depends on the #$PathSystem. Note also that in some cases (such as talking about relations between different #$PathSystems), using (#$LinksFn SYS) to denote the set of all links in SYS is more convenient than using the predicate #$linkInSystem.
> guid: bfe946ac-9c29-11b1-9dad-c379636f7270
> direct instance of: #$AsymmetricBinaryPredicate
> direct specialization of: #$pathInSystem

#$linkBetweenInSystem link between in system

> (#$linkBetweenInSystem LINK X Y SYS) means that in the #$PathSystem SYS, the #$Path-Simple LINK (a link in SYS, so that (#$linkInSystem LINK SYS) holds) has as its two end points X and Y (nodes in SYS, so that both (#$nodeInSystem X SYS) and (#$nodeInSystem Y SYS) hold). Since LINK connects the two end points X and Y when (#$linkBetweenInSystem LINK X Y SYS) holds, (#$linkBetweenInSystem LINK X Y SYS) implies (#$pathBetween LINK X Y). A link in a path system is a path whose end points are nodes in the system, and which has no other nodes along it (although it may have any number of non-node points along it). For each link LINK in SYS, there is a unique pair {X, Y} of different nodes in SYS such that (#$linkBetweenInSystem LINK X Y SYS) and (#$linkBetweenInSystem LINK Y X SYS) hold, and for any two nodes in SYS, there could be several different ('parallel') links between them. No point in SYS that is not a node can be an end point of a link. Only a node in SYS can be an 'intersection' point in SYS (see #$junctionInSystem), which implies that there is, in the system SYS, no point on a link LINK between X and Y that is an 'intersection' point of LINK and another link or a loop.
> guid: be07a2f8-9c29-11b1-9dad-c379636f7270
> direct instance of: #$QuaternaryPredicate
> direct specialization of: #$pathBetweenInSystem

#$pathInSystem path in system

> A #$PathSystemCycLConstant predicate that relates a given path system to each of the simple paths in it. (#$pathInSystem PATH SYS) means that PATH is a path in the system SYS. What constitutes a path in SYS is defined as follows. (i) Every link in SYS (see #$linkInSystem) is a path in SYS. (ii) Every subpath between points (see #$SubPathBetweenFn and #$pointInSystem) on a link in SYS is a path in SYS. (iii) The concatenation of paths PATH1 and PATH2 in SYS (see #$JoinPathsFn) is a path in SYS, provided there is only one point shared by both paths. Every path in the system is constructible by applying (i), (ii), and/or (iii) finitely many times. So for example a path in SYS might start somewhere along a link, go through several other links and nodes (see #$nodeInSystem), and end somewhere along a link. Or the path might simply go from one node to another. See also #$pathBetweenInSystem and #$linkBetweenInSystem.
> guid: bd5a56eb-9c29-11b1-9dad-c379636f7270
> direct instance of: #$AsymmetricBinaryPredicate

#$pathBetweenInSystem path between in system

> (#$pathBetweenInSystem PATH X Y SYS) means that PATH is a path in the #$PathSystem SYS, and X and Y are the end points (in the #$PathSystem) of PATH. If PATH is a link of the system (see #$linkInSystem), (#$pathBetweenInSystem PATH X Y SYS) iff (#$linkBetweenInSystem PATH X Y SYS). Note that there can be multiple paths in SYS between the same two points in SYS (which may or may not be nodes in SYS; see #$nodeInSystem). See also #$pathBetween when no #$PathSystem is specified.
> guid: c0e14545-9c29-11b1-9dad-c379636f7270
> direct instance of: #$QuaternaryPredicate

#$cycleInSystem cycle in system

> (#$cycleInSystem CYCLE SYS) means that CYCLE is a cycle in the path system SYS. A cycle in SYS is either a loop in SYS or the concatenation of two different paths PATH1 and PATH2 in SYS satisfying the following conditions: (i) there are two points X and Y in SYS such that (#$pathBetweenInSystem PATH1 X Y SYS) and (#$pathBetweenInSystem PATH2 X Y SYS), and (ii) no point in SYS other than X and Y is on both PATH1 and PATH2.
> guid: be94da63-9c29-11b1-9dad-c379636f7270
> direct instance of: #$AsymmetricBinaryPredicate

#$loopInSystem loop in system **COMMENT NOT REVIEWED** **GAFs NOT REVIEWED**

> (#$loopInSystem LOOP SYS) means that LOOP is a 'loop' in SYS, which is like a link in SYS except that it has exactly one node on it as if it is a link whose two end nodes are the same. Each loop in SYS is also a cycle in SYS, see #$cycleInSystem. The differences between a loop and a (non-loop) cycle in SYS include that (i) there is exactly one point in SYS on a loop (which must be a node in SYS), but there may in general be any finite number of nodes (and even as many points as there are real numbers) on some (non-loop) cycle in SYS, and that (ii) The unique node in SYS on a loop may or may not be an end point of a link in SYS, but each node on a (non-loop) cycle in SYS must be an end point of at least two links in SYS. These imply that there can be at most one 'intersection point' on a loop in SYS but there can be any finite number of 'intersection points' on a (non-loop) cycle in SYS. See #$pointOnCycle and #$junctionInSystem. Note that under current treatment of loops in a path system, if one would like to talk about a 'loop' in a path system a 'part' of which is a path in the system, then he/she should make it a cycle rather than a loop in the system because according to what we said above, no 'part' of a loop in the system can be presented as a path in the system. Note also that in some cases (such as talking about relations between different #$PathSystems), using (#$LoopsInSystemFn SYS) to denote the set of all loops in SYS is more convenient than using the predicate #$loopInSystem.
> guid: bf2899fb-9c29-11b1-9dad-c379636f7270
> direct instance of: #$AsymmetricBinaryPredicate
> direct specialization of: #$cycleInSystem

#$junctionInSystem junction in system **COMMENT NOT REVIEWED** **GAFs NOT REVIEWED**

> (#$junctionInSystem JUNCTION SYS) means that JUNCTION is a junction in the #$PathSystem SYS, i.e., a node in SYS that is an 'intersection' or 'branching point' of links or loops in SYS. (For the case when no SYS is specified, see #$JunctionOfPaths.) Formally, a node X in SYS is a junction in SYS iff either there are three (different) links in SYS such that X is on all of them, or there are two (different) loops in SYS such that X is on both of them, or there is a link in SYS and there is a loop in SYS such that X is on both of them. For different kinds of junctions in a path system, see #$threeWayJunctionInSystem, #$fourWayJunctionInSystem.
> guid: bd9e3c53-9c29-11b1-9dad-c379636f7270
> direct instance of: #$AsymmetricBinaryPredicate
> direct specialization of: #$nodeInSystem

#$threeWayJunctionInSystem three way junction in system **COMMENT NOT REVIEWED** **GAFs NOT REVIEWED**

> (#$threeWayJunctionInSystem JUNCT SYS) means that JUNCT is a 3-way junction in the specified #$PathSystem SYS. Formally, a 3-way junction in SYS is any point (actually, any node) X in SYS such that either there are exactly 3 links and no loops in SYS that X is on, or there are exactly 1 link and 1 loop in SYS that X is on. See #$junctionInSystem. When the junction is is simply a customary junction not based on a specified #$PathSystem, use #$ThreeWayJunctionOfPaths.
> guid: c0d729ee-9c29-11b1-9dad-c379636f7270
> direct instance of: #$AsymmetricBinaryPredicate
> direct specialization of: #$finitaryJunctionInSystem #$junctionInSystem

#$fourWayJunctionInSystem four way junction in system

> (#$fourWayJunctionInSystem JUNCT SYS) means that JUNCT is a 4-way junction in the #$PathSystem SYS. Formally, a 4-way junction in SYS is any node X in SYS such that either there are exactly 4 links and no loops in SYS that X is on, there are exactly 2 loops and no links in SYS that X is on, or there are exactly 2 links and 1 loop in SYS that X is on.
> guid: be3e5a74-9c29-11b1-9dad-c379636f7270
> direct instance of: #$AsymmetricBinaryPredicate
> direct specialization of: #$finitaryJunctionInSystem

#$n-WayJunctionInSystem n - way junction in system **COMMENT NOT REVIEWED** **GAFs NOT REVIEWED**

> (#$n-WayJunctionInSystem X N SYS) means that X is an N-way junction in the #$PathSystem SYS, where N is a natural number greater than 2. This means that exactly N ends of links (or of loops) join at X, in the system SYS.
> guid: bedacf03-9c29-11b1-9dad-c379636f7270
> direct instance of: #$TernaryPredicate

#$finitaryJunctionInSystem finitary junction in system **COMMENT NOT REVIEWED** **GAFs NOT REVIEWED**

> (#$finitaryJunctionInSystem X SYS) means that X is a finitary junction in the #$PathSystem SYS, i.e., X is an intersection joining only finitely many links and loops in SYS. More strictly, a junction X in a #$PathSystem SYS is finitary if there are only finitely many links and loops in SYS that X is on. As examples, all 3-way or 4-way junctions in SYS are finitary junctions. See #$threeWayJunctionInSystem, #$fourWayJunctionInSystem, #$junctionInSystem and #$FinitaryJunctionPathSystem
> guid: c089afb9-9c29-11b1-9dad-c379636f7270
> direct instance of: #$AsymmetricBinaryPredicate
> direct specialization of: #$junctionInSystem

#$deadEndInSystem dead end in system

> A #$PathSystemCycLConstant that is a specialization of #$nodeInSystem. (#$deadEndInSystem END SYS) means that END is a dead-end node in the #$PathSystem SYS. A node END in SYS is a dead-end node in SYS if there is exactly one link LINK in SYS that END is on and END is not on any loop in SYS. One easy way to illustrate a deadend END in SYS is to picture it as a node with only one path (possibly very short ) in the system through which one can approach or leave END. Note that no totally isolated node in SYS can be a deadend in SYS, nor can any point in SYS that is on a loop in SYS. If there is no specified path-system in which the path ends, but the ending is a dead end of a #$Path-Customary like a road or wire, then use #$pathTerminus instead.
> guid: c12c9294-9c29-11b1-9dad-c379636f7270
> direct instance of: #$AsymmetricBinaryPredicate
> direct specialization of: #$nodeInSystem

#$isolatedNodeInSystem isolated node in system

> (#$isolatedNodeInSystem NODE SYSTEM) means that the node NODE in the #$PathSystem SYSTEM is an isolated point in SYSTEM, i.e., NODE is not on any link or loop in SYSTEM. Note that an isolated point in SYSTEM must be a node in SYSTEM.
> guid: c0f07b4a-9c29-11b1-9dad-c379636f7270
> direct instance of: #$AsymmetricBinaryPredicate
> direct specialization of: #$nodeInSystem

#$connectedInSystem connected in system **COMMENT NOT REVIEWED** **GAFs NOT REVIEWED**

> (#$connectedInSystem X Y SYS) means that there is a path PATH in the #$PathSystem SYS such that (#$pathBetweenInSystem PATH X Y SYS) holds, or else X and Y are the same point in SYS. This predicate applies to a particular #$PathSystem, and the connectedness is an equivalence relation on that system, i.e., it is reflexive, transitive and symmetrical on that system.
> guid: c10e39c8-9c29-11b1-9dad-c379636f7270
> direct instance of: #$TernaryPredicate

#$nodeCutSetInSystem node cut set in system **COMMENT NOT REVIEWED** **GAFs NOT REVIEWED**

> (#$nodeCutSetInSystem SET SYS) means that the set SET of nodes in the #$ConnectedPathSystem SYS is a node-cut set in SYS, i.e., SET is a subset of (#$NodesFn SYS) such that cutting of all nodes in SET from SYS results in a disconnected path system. More strictly, to say that SET is a node-cut set in SYS, we mean that SET is a proper subset of (#$NodesFn SYS) and (#$NodesCut-SubSystemFn SYS SET) is not a #$ConnectedPathSystem. Note that when (#$nodeCutSetInSystem SET SYS) holds, there could be some proper subset SUBSET of SET such that (#$nodeCutSetInSystem SUBSET SYS) also holds. If you want a minimal node-cut set, without redundant nodes, use #$nodeCutMinimalSetInSystem instead of #$nodeCutSetInSystem.
> guid: bec75e5d-9c29-11b1-9dad-c379636f7270
> direct instance of: #$AsymmetricBinaryPredicate

#$linkCutSetInSystem link cut set in system **COMMENT NOT REVIEWED** **GAFs NOT REVIEWED**

> (#$linkCutSetInSystem SET SYS) means that the set SET of links in the #$ConnectedPathSystem SYS is a link-cut set in SYS, i.e., SET is a subset of (#$LinksFn SYS) such that cutting of all links in SET from SYS results in a disconnected path system. More strictly, to say that SET is a link-cut set in SYS, we mean that (#$LinksCut-SubSystemFn SYS SET) is not a #$ConnectedPathSystem. Note that when (#$linkCutSetInSystem SET SYS) holds, there could be some proper subset SUBSET of SET such that (#$linkCutSetInSystem SUBSET SYS) also holds. If you want a minimal link-cut set, without redundant links, use #$linkCutMinimalSetInSystem instead of #$linkCutSetInSystem.
> guid: bf83cdf3-9c29-11b1-9dad-c379636f7270
> direct instance of: #$AsymmetricBinaryPredicate

#$nodeCutMinimalSetInSystem node cut minimal set in system **COMMENT NOT REVIEWED** **GAFs NOT REVIEWED**

> (#$nodeCutMinimalSetInSystem SET SYS) means that the set SET of nodes in the #$ConnectedPathSystem SYS is a minimal node-cut set in SYS, i.e., SET is a subset of (#$NodesFn SYS) such that (#$nodeCutSetInSystem SET SYS) holds, and such that no proper subset SUBSET of SET satisfies (#$nodeCutSetInSystem SUBSET SYS).
> guid: bf95b7c3-9c29-11b1-9dad-c379636f7270
> direct instance of: #$AsymmetricBinaryPredicate

#$linkCutMinimalSetInSystem link cut minimal set in system **COMMENT NOT REVIEWED** **GAFs NOT REVIEWED**

> (#$linkCutMinimalSetInSystem SET SYS) means that the set SET of links in the #$ConnectedPathSystem SYS is a minimal link-cut set in SYS, i.e., SET is a subset of (#$LinksFn SYS) such that (#$linkCutSetInSystem SET SYS) holds, and such that no proper subset SUBSET of SET satisfies (#$linkCutSetInSystem SUBSET SYS).
> guid: c0039140-9c29-11b1-9dad-c379636f7270
> direct instance of: #$AsymmetricBinaryPredicate

#$cutNodeInSystem cut node in system **COMMENT NOT REVIEWED** **GAFs NOT REVIEWED**

> (#$cutNodeInSystem X SYS) means that X is a single node in the #$ConnectedPathSystem SYS whose removal would cause the system to be disconnected. Thus {X}, i.e., (#$TheSet X), is a node-cut-set in SYS. That is to say, (#$cutNodeInSystem X SYS) holds if and only if (#$nodeCutSetInSystem (#$TheSet X) SYS) holds. Note that since SYS is a #$ConnectedPathSystem whenever (#$cutNodeInSystem X SYS) holds, it is easy to see that (#$cutNodeInSystem X SYS) holds if and only if (#$nodeCutMinimalSetInSystem (#$TheSet X) SYS) holds.
> guid: be42c63f-9c29-11b1-9dad-c379636f7270
> direct instance of: #$AsymmetricBinaryPredicate
> direct specialization of: #$nodeInSystem

#$cutLinkInSystem cut link in system **COMMENT NOT REVIEWED** **GAFs NOT REVIEWED**

> (#$cutLinkInSystem LINK SYS) means that LINK is a single link in the #$ConnectedPathSystem SYS whose removal would cause the system to be disconnected. Thus {LINK}, i.e., (#$TheSet LINK), is a link-cut-set in SYS. That is to say, (#$cutLinkInSystem LINK SYS) holds if and only if (#$linkCutSetInSystem (#$TheSet LINK) SYS) holds. Note that since SYS is a #$ConnectedPathSystem whenever (#$cutLinkInSystem LINK SYS) holds, it is easy to see that (#$cutLinkInSystem LINK SYS) holds if and only if (#$linkCutMinimalSetInSystem (#$TheSet LINK) SYS) holds.
> guid: c112c49f-9c29-11b1-9dad-c379636f7270
> direct instance of: #$AsymmetricBinaryPredicate
> direct specialization of: #$linkInSystem

#$nodeCutSetBetweenInSystem node cut set between in system **COMMENT NOT REVIEWED** **GAFs NOT REVIEWED**

> (#$nodeCutSetBetweenInSystem SET X Y SYS) means that SET is a node-cut-set in the #$ConnectedPathSystem SYS, and that the points X and Y in SYS are disconnected in the subsystem of SYS obtained by cutting all nodes in SET from SYS. More strictly, (#$nodeCutSetBetweenInSystem SET X Y SYS) is true if and only if (#$nodeCutSetInSystem SET SYS) is true and (#$connectedInSystem X Y (#$LinksCut-SubSystemFn SYS SET)) is false.
> guid: c089e511-9c29-11b1-9dad-c379636f7270
> direct instance of: #$QuaternaryPredicate

#$linkCutSetBetweenInSystem link cut set between in system **COMMENT NOT REVIEWED** **GAFs NOT REVIEWED**

> (#$linkCutSetBetweenInSystem SET X Y SYS) means that SET is a link-cut-set in the #$ConnectedPathSystem SYS, and that the points X and Y in SYS are disconnected in the subsystem of SYS obtained by cutting all links in SET from SYS. More strictly, (#$linkCutSetBetweenInSystem SET X Y SYS) is true if and only if (#$linkCutSetInSystem SET SYS) is true and (#$connectedInSystem X Y (#$LinksCut-SubSystemFn SYS SET)) is false.
> guid: c0a7846b-9c29-11b1-9dad-c379636f7270
> direct instance of: #$QuaternaryPredicate

#$cutNodeBetweenInSystem cut node between in system **COMMENT NOT REVIEWED** **GAFs NOT REVIEWED**

> (#$cutNodeBetweenInSystem NODE X Y SYS) means that NODE is a node somewhere between the points X and Y in the #$ConnectedPathSystem SYS, the removal of which would leave X and Y in disconnected components. That is to say, (#$cutNodeBetweenInSystem NODE X Y SYS) holds if and only if (#$nodeCutSetBetweenInSystem (#$TheSet NODE) X Y SYS) holds.
> guid: c10cf0a0-9c29-11b1-9dad-c379636f7270
> direct instance of: #$QuaternaryPredicate

#$cutLinkBetweenInSystem cut link between in system **COMMENT NOT REVIEWED** **GAFs NOT REVIEWED**

> (#$cutLinkBetweenInSystem LINK X Y SYS) means that LINK is a link somewhere between the points X and Y in the #$ConnectedPathSystem SYS, the removal of which would leave X and Y in disconnected components. That is to say, (#$cutLinkBetweenInSystem LINK X Y SYS) holds if and only if (#$linkCutSetBetweenInSystem (#$TheSet LINK) X Y SYS) holds.
> guid: beda4976-9c29-11b1-9dad-c379636f7270
> direct instance of: #$QuaternaryPredicate

#$linkFromToInSystem link from to in system **COMMENT NOT REVIEWED** **GAFs NOT REVIEWED**

> (#$linkFromToInSystem LINK X Y SYS) means that SYS is a directed path system, (#$linkBetweenInSystem LINK X Y SYS) holds, and LINK is directed from X to Y in SYS (i.e., Y is accessible from X via LINK in SYS). Note that each link in a semi-directed path system (see #$Semi-DirectedPathSystem) must be directed one way or the other or both, and each link in a directed path system (see #$DirectedPathSystem) must be directed one way or the other but not both, and each link in a bidirected path system (see #$BidirectedPathSystem) must be directed in both ways.
> guid: bd989200-9c29-11b1-9dad-c379636f7270
> direct instance of: #$QuaternaryPredicate
> direct specialization of: #$pathFromToInSystem #$linkBetweenInSystem

#$pathFromToInSystem path from to in system

> This predicate is used to state that, in a given #$Semi-DirectedPathSystem, a certain directed path goes from one given point to another. (#$pathFromToInSystem PATH X Y SYS) means that, in SYS, PATH goes from X to Y, and this does not go against the directions of any of PATH's constituent links. To be precise, where SYS is a semi-directed path system, PATH is a path in SYS, and both X and Y are points in SYS, #$pathFromToInSystem can be defined inductively as follows. (i) For each link LINK in SYS, (#$pathFromToInSystem LINK X Y SYS) iff (#$linkFromToInSystem LINK X Y SYS). (ii) For each link LINK in SYS, and for any points A and B in SYS such that either (#$betweenOnPath B A Y LINK) or (#$betweenOnPath A X B LINK) holds, (#$linkFromToInSystem LINK X Y SYS) holds iff (#$pathFromToInSystem (#$SubPathBetweenFn PATH A B) A B SYS) holds. (iii) If both (#$pathFromToInSystem PATH1 X Y SYS) and (#$pathFromToInSystem PATH2 Y Z SYS) hold, and if no point in SYS except Y is on both PATH1 and PATH2, then (#$pathFromToInSystem PATH X Z SYS) holds, where PATH is the concatenation of PATH1 and PATH2.
> guid: bdc0e56a-9c29-11b1-9dad-c379636f7270
> direct instance of: #$QuaternaryPredicate
> direct specialization of: #$pathBetweenInSystem

#$sinkNodeInSystem sink node in system **COMMENT NOT REVIEWED** **GAFs NOT REVIEWED**

> (#$sinkNodeInSystem X SYS) means that X is a sink node in the #$Semi-DirectedPathSystem SYS, i.e., a node to which all links attached to it come 'in', and from which no such links go 'out'. A sink node X in SYS is a node in SYS such that X is on some links but no loops in SYS, and such that each link in SYS that X is on is a link directed to X from another node. Another way to put this is that X is a node in SYS that is neither on any loop in SYS, nor an isolated node in SYS, nor a node from which a link in SYS is directed. See #$loopInSystem, #$isolatedNodeInSystem and #$linkFromToInSystem.
> guid: c08f515a-9c29-11b1-9dad-c379636f7270
> direct instance of: #$AsymmetricBinaryPredicate
> direct specialization of: #$nodeInSystem

#$sourceNodeInSystem source node in system **COMMENT NOT REVIEWED** **GAFs NOT REVIEWED**

> (#$sourceNodeInSystem X SYS) means that X is a source node in the #$Semi-DirectedPathSystem SYS, i.e., a node that all links attached to it go 'out' from it and no such links come 'in' to it. A source node X in SYS is a node in SYS such that X is on some links but no loops in SYS, and such that each link in SYS that X is on is a link directed from X to another node (but not from another to X). Another way to put this is that X is a node in SYS that is neither on a loop in SYS, nor an isolated node in SYS, nor a node to which a link in SYS is directed. Note that if a node X in SYS is on a 'bidirected' link, i.e., a link directed both from X to Y and from Y to X for some node Y, then X cannot be a source node in SYS. See #$loopInSystem, #$isolatedNodeInSystem and #$linkFromToInSystem.
> guid: c09036a1-9c29-11b1-9dad-c379636f7270
> direct instance of: #$AsymmetricBinaryPredicate
> direct specialization of: #$nodeInSystem

#$accessibleFromInSystem accessible from in system **COMMENT NOT REVIEWED** **GAFs NOT REVIEWED**

> (#$accessibleFromInSystem X Y SYS) means that X is accessible from Y in the #$Semi-DirectedPathSystem SYS, which in turn means that either X = Y or there is a path PATH from Y to X in SYS, i.e., (#$pathFromToInSystem PATH Y X SYS) holds. Note that if we fix a #$Semi-DirectedPathSystem SYS, the relation #$accessibleFromInSystem is reflexive and transitive (i.e., a quasi-order). If we fix a #$BidirectedPathSystem SYS, this relation is an equivalence relation, the same as #$connectedInSystem.
> guid: c0bc3f91-9c29-11b1-9dad-c379636f7270
> direct instance of: #$TernaryPredicate
> direct specialization of: #$connectedInSystem

#$directedCycleInSystem directed cycle in system **COMMENT NOT REVIEWED** **GAFs NOT REVIEWED**

> (#$directedCycleInSystem CYCLE SYS) means that CYCLE is a cycle in the #$Semi-DirectedPathSystem SYS that observes the directions of paths in SYS, i.e., all parts of CYCLE that are paths in SYS must observe the orders or directions of the paths in SYS. For example, if PATH is a path in SYS directed from X to Y in SYS, and if LINK is a link in SYS directed from Y to X, and in addition if LINK is different from PATH, then (#$JoinPathsIntoCycleFn (#$TheList X PATH Y LINK X)) is a cycle in SYS that observes the directions of paths in SYS. Note that in a #$Semi-DirectedPathSystem SYS, every loop in SYS is a directed cycle in SYS. Otherwise a directed cycle is a 'proper' cycle, i.e., it is the concatenation of some directed paths in SYS.
> guid: bfaae4c0-9c29-11b1-9dad-c379636f7270
> direct instance of: #$AsymmetricBinaryPredicate
> direct specialization of: #$cycleInSystem

### Path Functions That Do Not Require But Are Often Used With A Specified Path System

#$SubPathBetweenFn sub path between **COMMENT NOT REVIEWED** **GAFs NOT REVIEWED**

> Given a path PATH and different points X and Y on it, (#$SubPathBetweenFn PATH X Y) gives a unique subpath SUB of PATH that is between X and Y. This function should not be used without the context of a #$PathSystem because only with the reference to a path system can we be certain about the existence of such a subpath (e.g., Austin and Texas are different points on I-35, but there is no subpath of I35 that is between Austin and Texas). To put this in another way, let SYS be any path system. If PATH is a path in SYS and X and Y are different points in SYS and are also points on PATH, (#$SubPathBetweenFn PATH X Y) is the only subpath (in SYS) of PATH that is between X and Y. See #$pathInSystem. Note that this function is not defined on the cartesian product #$Path-Simple x #$Thing x #$Thing, but on a proper subset of it.
> guid: c08712ed-9c29-11b1-9dad-c379636f7270
> direct instance of: #$TernaryFunction #$PartialDenotationalFunction #$Individual

#$JoinPathsFn joining paths **COMMENT NOT REVIEWED** **GAFs NOT REVIEWED**

> A function that, when applied to a CHAIN as in (#$JoinPathsFn CHAIN) where CHAIN is a #$PathChain whose 'path-concatenation' results in a #$Path-Simple, returns the #$Path-Simple obtained by the concatenation. More strictly, let CHAIN be a #$PathChain (#$TheList POINT(1) PATH(1) ... POINT(n) PATH(n) POINT(n+1)) such that the concatenation of all the PATH(k)s is a #$Path-Simple. Then (#$JoinPathsFn CHAIN) is the result of concatenating PATH(1), ..., PATH(n), which is a single as-long or longer path. Note that this function is a partial function. Note also that for (#$JoinPathsFn (#$TheList POINT(1) PATH(1) ... POINT(n) PATH(n) POINT(n+1))) to be defined, all PATH(k)s must be instances of #$Path-Simple, and no PATH(j) and PATH(k) can be the same if j and k are different. Note, finally, that if all PATH(k)s are links, and all POINT(k)s are nodes, in a #$PathSystem, (#$JoinPathsFn (#$TheList POINT(1) PATH(1) ... POINT(n) PATH(n) POINT(n+1))) is defined if and only if all POINT(k)s are different.
> guid: bf7e1c54-9c29-11b1-9dad-c379636f7270
> direct instance of: #$PartialDenotationalFunction #$UnaryFunction #$Individual

#$JoinPathsIntoCycleFn joining paths into a cycle **COMMENT NOT REVIEWED** **GAFs NOT REVIEWED**

> A function that, when applied to a #$PathChain as in (#$JoinPathsIntoCycleFn (#$TheList POINT(1) PATH(1) ... POINT(n) PATH(n) POINT(n+1))) where the concatenation of all PATH(k)s results in a #$Path-Cyclic, gives the #$Path-Cyclic obtained by the concatenation. Note that this function is a partial function. Note also that in order for (#$JoinPathsIntoCycleFn (#$TheList POINT(1) PATH(1) ... POINT(n) PATH(n) POINT(n+1))) to be defined, all PATH(k)s must be different instances of #$Path-Simple, and all POINT(k)s must be different, except POINT(1) = POINT(n+1). Note, finally, that in a #$PathSystem, it is usually convenient to use nodes and links in the system as items in the list, as opposed to including non-node points along links.
> guid: be226814-9c29-11b1-9dad-c379636f7270
> direct instance of: #$UnaryFunction #$Individual

#$LoopsInSystemFn loops in system fn

> A function from path-systems to the set-or-collection of loops in those systems. (#$LoopsInSystemFn SYSTEM) is the #$SetOrCollection (q.v.) of all loops (see #$loopInSystem) in the #$PathSystem (q.v.) SYSTEM.
> guid: c0bf1c7f-9c29-11b1-9dad-c379636f7270
> direct instance of: #$UnaryFunction #$Individual

#$LinksFn links fn **COMMENT NOT REVIEWED** **GAFs NOT REVIEWED**

> For each #$PathSystem SYS, (#$LinksFn SYS) denotes the set of all links in SYS (see #$PathSystem). Note that the function #$LinksFn and the predicate #$linkInSystem are interdefinable. We normally use #$LinksFn, for convenience, when we consider some relations between different path systems even though for a single path system SYS, we can also replace each (#$linkInSystem X SYS) by (#$elementOf X (#$LinksFn SYS)).
> guid: beefa999-9c29-11b1-9dad-c379636f7270
> direct instance of: #$UnaryFunction #$Individual

#$PointsInSystemFn points in system fn

> A function from path-systems to the set-or-collections of points in those systems. (#$PointsInSystemFn SYSTEM) is the #$SetOrCollection (q.v.) of all points (see #$pointInSystem) in the #$PathSystem (q.v.) SYSTEM. See also #$NodesInSystemFn.
> guid: bda2010c-9c29-11b1-9dad-c379636f7270
> direct instance of: #$UnaryFunction #$Individual

#$NodesInSystemFn nodes in system fn

> A function from path-systems to the set-or-collections of nodes in those systems. (#$NodesInSystemFn SYSTEM) is the #$SetOrCollection (q.v.) of all nodes (see #$nodeInSystem) in the #$PathSystem (q.v.) SYSTEM. See also #$PointsInSystemFn.
> guid: bea523d2-9c29-11b1-9dad-c379636f7270
> direct instance of: #$UnaryFunction #$Individual

#$SetOfLoopsAtNodeFn set of loops at node fn **COMMENT NOT REVIEWED** **GAFs NOT REVIEWED**

> A function that, when applied to a #$PathSystem SYS and a node X in SYS as in (#$SetOfLoopsAtNodeFn X SYS), returns the set of all loops in SYS that X is on, i.e., the set of all loops LOOP in SYS such that (#$pointOnCycle X LOOP). (A loop in SYS is a #$Path-Cyclic that goes from a node immediately back to the same node, see #$loopInSystem.) Note that (#$SetOfLoopsAtNodeFn X SYS) = #$TheEmptySet if there is no loop in SYS that X is on.
> guid: bdec6db7-9c29-11b1-9dad-c379636f7270
> direct instance of: #$BinaryFunction #$Individual

#$SetOfLinksAtNodeFn set of links at node fn

> A function from path-systems and nodes in those path-systems to set-or-collections of links in those systems. (#$SetOfLinksAtNodeFn NODE SYS) is the #$SetOrCollection (q.v.) of all links in the #$PathSystem SYS that NODE is on, i.e., the set-or-collection of all links LINK in SYS such that (#$linkBetweenInSystem LINK NODE OTHER-NODE SYS) holds for some OTHER-NODE. Note that if SYS is a #$Semi-DirectedPathSystem (q.v.) and NODE is a node in SYS, then (#$SetOfLinksAtNodeFn NODE SYS) equals the union of (#$InwardLinkSetFn NODE SYS) and (#$OutwardLinkSetFn NODE SYS) (these two set-or-collections will overlap if there are any 'bidirected' links at that node). Note also that (#$SetOfLinksAtNodeFn NODE SYS) = #$TheEmptySet if there is no link in SYS that is between NODE and another node in SYS. Loops, if any, are not included as links.
> guid: bfe64dd3-9c29-11b1-9dad-c379636f7270
> direct instance of: #$BinaryFunction #$Individual

#$LinksCut-SubSystemFn links cut - sub system fn **COMMENT NOT REVIEWED** **GAFs NOT REVIEWED**

> A function that, when applied to a #$PathSystem SYS and a set SET of links in SYS (i.e., a subset of (#$LinksFn SYS)) as in (#$NodesCut-SubSystemFn SYS SET), gives the subsystem SUBSYS of SYS obtained by cutting all links in SET from SYS. The 'cutting' of links will not remove any nodes, but removes those points on the links that are not nodes. More strictly, SUBSYS is determined as follows: (i) SUBSYS is a subsystem of SYS (i.e., (#$subPathSystems SYS SUBSYS) holds), (ii) (#$NodesFn SUBSYS) = (#$NodesFn SYS), (#$LinksFn SUBSYS) = (#$LinksFn SYS) - SET, (#$LoopsFn SUBSYS) = (#$LoopsFn SYS) and (#$PointsFn SUBSYS) = (#$PointsFn SYS) - {X: X is a non-node-point in SYS and X is on a LINK for some LINK in SET}.
> guid: c02526f4-9c29-11b1-9dad-c379636f7270
> direct instance of: #$BinaryFunction #$ReifiableFunction #$Individual

#$NodesCut-SubSystemFn nodes cut - sub system fn **COMMENT NOT REVIEWED** **GAFs NOT REVIEWED**

> A function that, when applied to a #$PathSystem SYS and a set SET of nodes in SYS (i.e., a subset of (#$NodesFn SYS)) as in (#$NodesCut-SubSystemFn SYS SET), gives the subsystem SUBSYS of SYS obtained by cutting all nodes in SET from SYS. The 'cutting' of nodes also removes all their attached loops and links (and points on them if any). More strictly, SUBSYS is determined as follows: (i) SUBSYS is a subsystem of SYS (i.e., (#$subPathSystems SYS SUBSYS) holds), (ii) (#$NodesFn SUBSYS) = (#$NodesFn SYS) - SET, (#$LinksFn SUBSYS) = (#$LinksFn SYS) - {LINK: LINK is a link in SYS and X is on LINK for some node X in SET}, (#$PointsFn SUBSYS) = ((#$PointsFn SYS) - SET) - {Y: Y is a non-node-point in SYS and Y is on LINK for some LINK in ((#$LinksFn SYS) - (#$LinksFn SUBSYS)), and (#$LoopsFn SUBSYS) = (#$LoopsFn SYS) - {LOOP: LOOP is a loop in SYS and X is on LOOP for some X in SET}. Note that since there is no 'empty' #$PathSystem, SET must be a proper subset of (#$NodesFn SYS) for (#$NodesCut-SubSystemFn SYS SET) to be defined.
> guid: c074589c-9c29-11b1-9dad-c379636f7270
> direct instance of: #$BinaryFunction #$ReifiableFunction #$Individual

#$PathFromFn path from **COMMENT NOT REVIEWED** **GAFs NOT REVIEWED**

> For each instance SYS of #$DirectedPathSystem, and for each path PATH in SYS, (#$PathFromFn PATH SYS) denotes 'the starting point' of PATH, i.e., the unique point X in SYS such that (#$pathFromToInSystem PATH X Y SYS) for some point Y in SYS (where Y is actually the unique point in SYS such that (#$PathToFn PATH SYS) = Y).
> guid: c0317721-9c29-11b1-9dad-c379636f7270
> direct instance of: #$BinaryFunction #$Individual

#$PathToFn path to

> An instance of #$BinaryFunction. For each instance SYS of #$DirectedPathSystem, and for each path PATH in SYS, (#$PathToFn PATH SYS) is 'the ending point' of PATH, i.e., the unique point END-POINT in SYS such that (#$pathFromToInSystem PATH START-POINT END-POINT SYS) holds for some point START-POINT in SYS (where START-POINT is the unique point in SYS such that (#$PathFromFn PATH SYS) = START-POINT).
> guid: c06aa6a9-9c29-11b1-9dad-c379636f7270
> direct instance of: #$BinaryFunction #$Individual

#$SingleSourceFn single source fn **COMMENT NOT REVIEWED** **GAFs NOT REVIEWED**

> A function, when applied to a #$BoundedDirectedPathSystem SYS as in (#$SingleSourceFn SYS), returns the unique source node X in SYS, i.e., the node in SYS that has only outward links. Note that since SYS is a #$BoundedDirectedPathSystem, there can be no source node in SYS other than (#$SingleSourceFn SYS). See also #$sourceNodeInSystem.
> guid: be90e9c2-9c29-11b1-9dad-c379636f7270
> direct instance of: #$UnaryFunction #$Individual

#$SingleSinkFn single sink fn **COMMENT NOT REVIEWED** **GAFs NOT REVIEWED**

> A function, when applied to a #$BoundedDirectedPathSystem SYS as in (#$SingleSinkFn SYS), returns the unique sink node X in SYS, i.e., the node in SYS that has only inward links. Note that since SYS is a #$BoundedDirectedPathSystem, there can be no sink node in SYS other than (#$SingleSinkFn SYS). See also #$sinkNodeInSystem.
> guid: be989456-9c29-11b1-9dad-c379636f7270
> direct instance of: #$UnaryFunction #$Individual

#$OutwardLinkSetFn outward link set fn **COMMENT NOT REVIEWED** **GAFs NOT REVIEWED**

> A function, when applied to a #$Semi-DirectedPathSystem SYS and a node X in SYS as in (#$OutwardLinkSetFn X SYS), returns the set of all links directed outward from X, i.e., the set of links in SYS each of which is directed in SYS from X to some other node in SYS. Note that if SYS is a #$DirectedPathSystem, (#$OutwardLinkSetFn X SYS) is disjoint with (#$InwardLinkSetFn X SYS). If SYS is not a #$DirectedPathSystem, however, (#$OutwardLinkSetFn X SYS) is not in general disjoint with (#$InwardLinkSetFn X SYS) because a 'bidirected' link, if any, belongs to both sets. So for an inexperienced user, it is recommended to use a #$DirectedPathSystem as the second argument of this function. Note also that loops, if any, are not included as links.
> guid: bdd00dc7-9c29-11b1-9dad-c379636f7270
> direct instance of: #$BinaryFunction #$Individual

#$InwardLinkSetFn inward link set fn **COMMENT NOT REVIEWED** **GAFs NOT REVIEWED**

> A function, when applied to a #$Semi-DirectedPathSystem SYS and a node X in SYS as in (#$InwardLinkSetFn X SYS), returns the set of all links directed toward X, i.e., the set of links in SYS each of which is directed in SYS from some other node to X. Note that if SYS is a #$DirectedPathSystem, (#$InwardLinkSetFn X SYS) is disjoint with (#$OutwardLinkSetFn X SYS). If SYS is not a #$DirectedPathSystem, however, (#$InwardLinkSetFn X SYS) is not in general disjoint with (#$OutwardLinkSetFn X SYS) because a 'bidirected' link, if any, belongs to both sets. So for an inexperienced user, it is recommended to use a #$DirectedPathSystem as the second argument of this function. Note also that loops, if any, are not included as links.
> guid: bfa6ee9e-9c29-11b1-9dad-c379636f7270
> direct instance of: #$BinaryFunction #$Individual

#$SubSystemUnderTraversalFn sub system under traversal fn **COMMENT NOT REVIEWED** **GAFs NOT REVIEWED**

> A function, when applied to a #$PathSystem SYS and a #$Traversal TRAV in SYS as in (#$SubSystemUnderTraversalFn SYS TRAV), returns the smallest point-closed subsystem SUB of SYS such that TRAV is a traversal in SUB (see #$smallestSubSystemUnderTraversal, #$traversalInSystem and #$pointClosedSubSystems). Note that 'smallest' here means that no link LINK between X and Y in SYS is a link in SUB if neither (#$TraversalFn (#$TheList X LINK Y)) nor (#$TraversalFn (#$TheList Y LINK X)) is a #$subTraversals of TRAV. Note also that since SUB is a point-closed subsystem of SYS, every point in SYS that is on TRAV (see #$pointOnTraversal) is a point in SUB. Note finally that since SUB is the 'smallest' subsystem of SYS in which TRAV is a traversal, SUB must be a #$ConnectedPathSystem.
> guid: c10af9e3-9c29-11b1-9dad-c379636f7270
> direct instance of: #$BinaryFunction #$Individual

### Betweenness

#$betweenOnPath item between two others on some path **COMMENT NOT REVIEWED** **GAFs NOT REVIEWED**

> (#$betweenOnPath X Y Z PATH) means that X, Y and Z are points on the path PATH and X is between Y and Z. Note that this gives no ordering of Y and Z; it just claims that X is between them. Note: Given a #$Path-Customary PATH and points or places on PATH, #$betweenOnPath does not always determine a linear order (#$TotalOrdering) on the set of all points on PATH when PATH is not part of a specified #$PathSystem (since one thing on such a path -- #$onPath PATH -- may be part of another). However, in a specified #$PathSystem SYS, #$betweenOnPath does determine a linear order on the set of all points on PATH in SYS.
> guid: c0e50f87-9c29-11b1-9dad-c379636f7270
> direct instance of: #$QuaternaryPredicate

#$pathBetween path between the specified paths

> (#$pathBetween PATH X Y) means that the #$Path-Simple PATH goes between points (or places) X and Y, where X and Y do not 'overlap', and no further. Both X and Y have to be on PATH (see #$pointOnPath). Note that (#$pathBetween PATH X Y) is more specific than (#$pathConnects PATH X Y) because here the PATH cannot extend beyond X and Y. Within a particular #$PathSystem, a path's end points in the system are unique, and #$pathBetweenInSystem (q.v.) is restricted to paths and points in the system. When considered without a context of a path system, a path may have several different places at one end, such as Austin and Texas both being at the same end of some path along Highway I-35.
> guid: c065f088-9c29-11b1-9dad-c379636f7270
> direct instance of: #$TernaryPredicate
> direct specialization of: #$pathConnects

#$pathBetweenInSystem path between in system

> (#$pathBetweenInSystem PATH X Y SYS) means that PATH is a path in the #$PathSystem SYS, and X and Y are the end points (in the #$PathSystem) of PATH. If PATH is a link of the system (see #$linkInSystem), (#$pathBetweenInSystem PATH X Y SYS) iff (#$linkBetweenInSystem PATH X Y SYS). Note that there can be multiple paths in SYS between the same two points in SYS (which may or may not be nodes in SYS; see #$nodeInSystem). See also #$pathBetween when no #$PathSystem is specified.
> guid: c0e14545-9c29-11b1-9dad-c379636f7270
> direct instance of: #$QuaternaryPredicate

#$SubPathBetweenFn sub path between **COMMENT NOT REVIEWED** **GAFs NOT REVIEWED**

> Given a path PATH and different points X and Y on it, (#$SubPathBetweenFn PATH X Y) gives a unique subpath SUB of PATH that is between X and Y. This function should not be used without the context of a #$PathSystem because only with the reference to a path system can we be certain about the existence of such a subpath (e.g., Austin and Texas are different points on I-35, but there is no subpath of I35 that is between Austin and Texas). To put this in another way, let SYS be any path system. If PATH is a path in SYS and X and Y are different points in SYS and are also points on PATH, (#$SubPathBetweenFn PATH X Y) is the only subpath (in SYS) of PATH that is between X and Y. See #$pathInSystem. Note that this function is not defined on the cartesian product #$Path-Simple x #$Thing x #$Thing, but on a proper subset of it.
> guid: c08712ed-9c29-11b1-9dad-c379636f7270
> direct instance of: #$TernaryFunction #$PartialDenotationalFunction #$Individual

#$linkBetweenInSystem link between in system

> (#$linkBetweenInSystem LINK X Y SYS) means that in the #$PathSystem SYS, the #$Path-Simple LINK (a link in SYS, so that (#$linkInSystem LINK SYS) holds) has as its two end points X and Y (nodes in SYS, so that both (#$nodeInSystem X SYS) and (#$nodeInSystem Y SYS) hold). Since LINK connects the two end points X and Y when (#$linkBetweenInSystem LINK X Y SYS) holds, (#$linkBetweenInSystem LINK X Y SYS) implies (#$pathBetween LINK X Y). A link in a path system is a path whose end points are nodes in the system, and which has no other nodes along it (although it may have any number of non-node points along it). For each link LINK in SYS, there is a unique pair {X, Y} of different nodes in SYS such that (#$linkBetweenInSystem LINK X Y SYS) and (#$linkBetweenInSystem LINK Y X SYS) hold, and for any two nodes in SYS, there could be several different ('parallel') links between them. No point in SYS that is not a node can be an end point of a link. Only a node in SYS can be an 'intersection' point in SYS (see #$junctionInSystem), which implies that there is, in the system SYS, no point on a link LINK between X and Y that is an 'intersection' point of LINK and another link or a loop.
> guid: be07a2f8-9c29-11b1-9dad-c379636f7270
> direct instance of: #$QuaternaryPredicate
> direct specialization of: #$pathBetweenInSystem

#$nodeCutSetBetweenInSystem node cut set between in system **COMMENT NOT REVIEWED** **GAFs NOT REVIEWED**

> (#$nodeCutSetBetweenInSystem SET X Y SYS) means that SET is a node-cut-set in the #$ConnectedPathSystem SYS, and that the points X and Y in SYS are disconnected in the subsystem of SYS obtained by cutting all nodes in SET from SYS. More strictly, (#$nodeCutSetBetweenInSystem SET X Y SYS) is true if and only if (#$nodeCutSetInSystem SET SYS) is true and (#$connectedInSystem X Y (#$LinksCut-SubSystemFn SYS SET)) is false.
> guid: c089e511-9c29-11b1-9dad-c379636f7270
> direct instance of: #$QuaternaryPredicate

#$linkCutSetBetweenInSystem link cut set between in system **COMMENT NOT REVIEWED** **GAFs NOT REVIEWED**

> (#$linkCutSetBetweenInSystem SET X Y SYS) means that SET is a link-cut-set in the #$ConnectedPathSystem SYS, and that the points X and Y in SYS are disconnected in the subsystem of SYS obtained by cutting all links in SET from SYS. More strictly, (#$linkCutSetBetweenInSystem SET X Y SYS) is true if and only if (#$linkCutSetInSystem SET SYS) is true and (#$connectedInSystem X Y (#$LinksCut-SubSystemFn SYS SET)) is false.
> guid: c0a7846b-9c29-11b1-9dad-c379636f7270
> direct instance of: #$QuaternaryPredicate

#$cutNodeBetweenInSystem cut node between in system **COMMENT NOT REVIEWED** **GAFs NOT REVIEWED**

> (#$cutNodeBetweenInSystem NODE X Y SYS) means that NODE is a node somewhere between the points X and Y in the #$ConnectedPathSystem SYS, the removal of which would leave X and Y in disconnected components. That is to say, (#$cutNodeBetweenInSystem NODE X Y SYS) holds if and only if (#$nodeCutSetBetweenInSystem (#$TheSet NODE) X Y SYS) holds.
> guid: c10cf0a0-9c29-11b1-9dad-c379636f7270
> direct instance of: #$QuaternaryPredicate

#$cutLinkBetweenInSystem cut link between in system **COMMENT NOT REVIEWED** **GAFs NOT REVIEWED**

> (#$cutLinkBetweenInSystem LINK X Y SYS) means that LINK is a link somewhere between the points X and Y in the #$ConnectedPathSystem SYS, the removal of which would leave X and Y in disconnected components. That is to say, (#$cutLinkBetweenInSystem LINK X Y SYS) holds if and only if (#$linkCutSetBetweenInSystem (#$TheSet LINK) X Y SYS) holds.
> guid: beda4976-9c29-11b1-9dad-c379636f7270
> direct instance of: #$QuaternaryPredicate

### Relations Between Path Systems

#$PathSystem path systems

> The collection of all specified systems of paths and links, including both tangible path systems (such as the system of streets in a city) and abstract path systems (such as a multigraph). Each instance of #$PathSystem consists of a nonempty set of points (where each point is an instance of #$Thing, and is related to the instance of #$PathSystem via the predicate #$pointInSystem), a set of nodes (a subset of the set of points -- each node is related to the instance of #$PathSystem via the predicate #$nodeInSystem) a set of links (where each link is an instance of #$Path-Simple, and is related to the instance of #$PathSystem via the predicate #$linkInSystem), and optionally a set of loops (where each loop is an instance of #$Path-Cyclic, and is related to the instance of #$PathSystem via the predicate #$loopInSystem). In order to specify which link is between which two nodes in the system, which point is on which link in the system, which node is on which loop in the system, and so on, see the following predicates: #$pathBetween, #$pointOnPath, #$pointOnCycle, #$betweenOnPath, #$linkBetweenInSystem, #$junctionInSystem, #$deadEndInSystem, #$isolatedNodeInSystem, and #$connectedInSystem. Notable specializations of #$PathSystem include #$Semi-DirectedPathSystem, #$Multigraph, and #$SimplePathSystem. In order to specify the subsystem relation between path systems, see the predicate #$subPathSystems.
> guid: bfd62da4-9c29-11b1-9dad-c379636f7270
> direct instance of: #$Collection
> direct specialization of: #$Thing
> direct generalization of: #$SpatialPathSystem #$PointFinitePathSystem #$Semi-DirectedPathSystem #$ConnectedPathSystem #$SimplePathSystem #$Multigraph

#$subPathSystems sub path system **COMMENT NOT REVIEWED** **GAFs NOT REVIEWED**

> (#$subPathSystems SYS SUBSYS) means that the path system SUBSYS is a subsystem of the path system SYS. Technically, this means the following: (i) Every point in SUBSYS is a point in SYS, (ii) every node in SUBSYS is a node in SYS, (iii) every link in SUBSYS is a link in SYS, and (iv) every loop in SUBSYS is a loop in SYS. Some consequences of these conditions are as follows. (a) Every point in SUBSYS that is a node in SYS is a node in SUBSYS. (b) For any nodes X and Y in SUBSYS and each link LINK in SUBSYS, LINK is between X and Y in SYS iff it is between X and Y in SUBSYS. (c) For each point X in SYS that is not a node in SYS, if X is on a link in SYS that is not in SUBSYS, X is not in SUBSYS. (d) Isolated points and deadends in SUBSYS must be nodes in SYS. (e) For each loop LOOP in SUBSYS, the only node in SYS on LOOP must be a node in SUBSYS. (f) If SYS is a #$SimpleGraph-GraphTheoretic (or a #$Multigraph), all subsystems of SYS are #$SimpleGraph-GraphTheoretics (or #$Multigraphs). Predicates concerning particular kinds of subsystems of path systems, i.e., predicates that take #$subPathSystems as #$genlPreds, include #$linkClosedSubSystems, #$pointClosedSubSystems, and #$maximalConnectedSubSystems, etc. Predicates whose #$genlInverse are #$subPathSystems includes #$underlyingGraph.
> guid: c0e5d1f8-9c29-11b1-9dad-c379636f7270
> direct instance of: #$AntiSymmetricBinaryPredicate #$ReflexiveBinaryPredicate #$TransitiveBinaryPredicate

#$maximalConnectedSubSystems maximal connected sub systems

> (#$maximalConnectedSubSystems SYS SUB) means that SUB is a maximal connected subsystem of SYS, i.e., that SUB is an entire connected piece of SYS without other disconnected pieces of SYS. That is to say, (i) SUB is a connected path system (see the collection #$ConnectedPathSystem), and consequently must have at least one node, say NODE, in it, (ii) SUB is a subsystem of SYS, and (iii) for every connected subsystem SUB1 of SYS containing NODE, SUB1 is a subsystem of SUB. Thus a maximal connected subsystem SUB of a path system SYS must satisfy the conditions that (a) for each point X in SUB and each point Y in SYS that is not in SUB, X and Y are not connected in SYS, (b) for any nodes X and Y in SUB, for any link LINK in SYS between X and Y, LINK must also be in SUB, and (c) for each point X in SYS, if X is on a link in SYS which is also a link in SUB, then X must also be in SUB. It follows that if SUB is a maximal connected subsystem of SYS, SUB must be a link-closed subsystem as well as a point-closed subsystem of SYS. Another consequence is that if SUB is a maximal connected subsystem of SYS, and if X is a point in SUB and is on a loop in SYS, then the loop must also be in SUB.
> guid: be9e807b-9c29-11b1-9dad-c379636f7270
> direct instance of: #$AntiSymmetricBinaryPredicate #$TransitiveBinaryPredicate
> direct specialization of: #$linkClosedSubSystems #$pointClosedSubSystems

#$pointClosedSubSystems point closed sub systems **COMMENT NOT REVIEWED** **GAFs NOT REVIEWED**

> (#$pointClosedSubSystems SYS SUBSYS) means that the path system SUBSYS is a subsystem of the path system SYS (i.e., (#$subPathSystems SYS SUBSYS) holds) and SUBSYS 'preserves' all points in SYS that are on links in SUBSYS, i.e., if LINK is a link in SUBSYS (and hence is a link in SYS) and X is a point in SYS and is on LINK, then X must be a point in SUBSYS.
> guid: bfbab435-9c29-11b1-9dad-c379636f7270
> direct instance of: #$AntiSymmetricBinaryPredicate #$ReflexiveBinaryPredicate #$TransitiveBinaryPredicate
> direct specialization of: #$subPathSystems

#$linkClosedSubSystems link closed sub systems **COMMENT NOT REVIEWED** **GAFs NOT REVIEWED**

> (#$linkClosedSubSystems SYS SUBSYS) means that the path system SUBSYS is a subsystem of the path system SYS (i.e., (#$subPathSystems SYS SUBSYS) holds) and SUBSYS 'preserves' all links in SYS between nodes in SUBSYS, i.e., if (#$linkBetweenInSystem LINK X Y SYS) holds and X and Y are in SUBSYS, LINK is a link in SUBSYS.
> guid: bf4c45ab-9c29-11b1-9dad-c379636f7270
> direct instance of: #$AntiSymmetricBinaryPredicate #$ReflexiveBinaryPredicate #$TransitiveBinaryPredicate
> direct specialization of: #$subPathSystems

#$underlyingGraph underlying graph **COMMENT NOT REVIEWED** **GAFs NOT REVIEWED**

> (#$underlyingGraph RED SYS) means that (i) every node in SYS is a node in RED, (ii) every point in RED is a node in RED (and hence a node in SYS), and (iii) (#$linkClosedSubSystems SYS RED) holds. It is easy to see that when (#$underlyingGraph RED SYS) holds, RED must be an instance of #$Multigraph. But RED is not only a multi-graph, it is THE multi-graph that underlies the path system SYS, i.e., the only difference between SYS and RED is that SYS is obtainable by adding to RED some points that are on a link in RED between the end-nodes.
> guid: c0787b09-9c29-11b1-9dad-c379636f7270
> direct instance of: #$AntiSymmetricBinaryPredicate #$FunctionalPredicate #$TransitiveBinaryPredicate

#$directionPreservingSubSystems direction preserving sub systems

> (#$directionPreservingSubSystems SYS SUBSYS) means that (i) both SYS and SUBSYS are semi-directed path systems (see #$Semi-DirectedPathSystem), (ii) SUBSYS is a subsystem of SYS (so that (#$subPathSystems SYS SUBSYS) holds), and (iii) SUBSYS preserves the directions of links, in the following sense: for each link LINK in SUBSYS, (#$linkFromToInSystem LINK X Y SUBSYS) iff (#$linkFromToInSystem LINK X Y SYS).
> guid: c06e260d-9c29-11b1-9dad-c379636f7270
> direct instance of: #$AntiSymmetricBinaryPredicate #$TransitiveBinaryPredicate #$ReflexiveBinaryPredicate
> direct specialization of: #$subPathSystems

### Traversals Of Paths

#$PathChain path chains

> A specialization of #$List. Each path chain is a #$List LIST = (X(1) Y(1) X(2) Y(2) ... X(n) Y(n) X(n+1)) satisfying the following conditions: (i) each X(k) is a #$Thing (q.v.) and each Y(k) is a #$Path-Generic (q.v.), i.e., the length of LIST is an odd number greater than 2, every even-numbered position in LIST is a #$Path-Generic, and every odd-numbered item is a #$Thing. (ii) Each #$Path-Generic in LIST joins the points just before and after it in LIST. That is to say, (iia) if the kth item PATH in LIST is a #$Path-Simple (q.v.), and if A is the (k-1)th item and B is the (k+1)th item in LIST, then (#$pathBetween PATH A B) holds, and (iib) if the kth item CYCLE is a #$Path-Cyclic (q.v.), and if A is the (k-1)th item and B is the (k+1)th item in LIST, then (#$pointOnCycle A CYCLE) holds and A = B. Note that the concatenation of all the paths (simple or cyclic) in such a list results in a #$Traversal (q.v.). For example, letting PATH1 and PATH2 be instances of #$Path-Simple and CYCLE a #$Path-Cyclic, if (#$pathBetween PATH1 A B), (#$pathBetween PATH2 B C) and (#$pointOnCycle C CYCLE), then (#$TheList A PATH1 B PATH2 C CYCLE C) is a #$PathChain. Note that although each instance of #$PathChain determines a unique instance of #$Traversal that is from X(1) to X(n+1), many different #$PathChains may determine the same #$Traversal.
> guid: c0bb98f7-9c29-11b1-9dad-c379636f7270
> direct instance of: #$ObjectType
> direct specialization of: #$List

#$Traversal traversals **COMMENT NOT REVIEWED** **GAFs NOT REVIEWED**

> The collection of all traversals of paths and networks. A traversal is a trace of a pathway along pre-existing #$Path-Generics. It is the 'path-representation' of certain actual trajectories (instances of #$Trajectory) that are confined to paths. Different actual trajectories may have the same traversal; to see this, consider two cars driving along a block of 10th St. The actual car movements have different trajectories -- say, one drove straight while the other switched lanes many times. The two different trajectories are both characterized by the same traversal of that block of 10th Street. A traversal of a network of paths can be represented by (#$TraversalFn CHAIN) where CHAIN is a #$PathChain. We may choose to use a more detailed representation of the traversal, i.e., use a #$PathChain made of more, but shorter, paths. For example, we may use several paths to replace a cycle in CHAIN if we want to be clear about the direction in that part of the traversal, or we may have to replace a path in CHAIN by several 'shorter' paths if we want to preserve the fact that the object moved backward at a small part of PATH and then resumed its original direction. In summary, a traversal is a constraint on a trajectory and a characterization of it in terms of traversing pre-existing #$Path-Generics. Technically, a #$Traversal from A to B can be expressed as (#$TraversalFn CHAIN) where CHAIN is a #$PathChain such that the first item in CHAIN is A and the last is B (we can assert: (#$traversalFrom (#$TraversalFn CHAIN) A) and (#$traversalTo (#$TraversalFn CHAIN) B)). Related constants include #$TraversalFn, #$traversalFrom, #$traversalTo, #$pointOnTraversal, #$subTraversals, #$traversalPassesThrough, #$traversalInSystem, etc. Note that a #$Traversal, unlike a #$Path-Generic, can cross itself, i.e., can 'pass through' a point on it many times. (Mathematically: given a #$PathSystem or #$CustomarySystemOfLinks, a #$Traversal of it is a directed path that has a homomorphism into that system.)
> guid: be9b2377-9c29-11b1-9dad-c379636f7270
> direct instance of: #$FirstOrderCollection
> direct specialization of: #$Individual

#$TraversalFn traversal fn **COMMENT NOT REVIEWED** **GAFs NOT REVIEWED**

> A function to obtain a traversal from a chain of points and paths. For example, (#$TraversalFn CHAIN), with the #$PathChain CHAIN = (#$TheList X(1) Y(1) ... X(n) Y(n) X(n+1)), gives a #$Traversal that starts at point X(1), moves to point X(2) through path Y(1), ..., etc. and stops at point X(n+1). Note that (#$TraversalFn CHAIN1) and (#$TraversalFn CHAIN2) may denote the same #$Traversal even when CHAIN1 is different from CHAIN2. This is due to the fact that the same path can be obtained by concatenating different path chains and that cycles can be obtained by concatenating paths in several combinations.
> guid: be592e11-9c29-11b1-9dad-c379636f7270
> direct instance of: #$UnaryFunction #$Individual

#$traversalFrom traversal from

> (#$traversalFrom TRAV POINT) means that POINT is a starting point of the #$Traversal TRAV along some paths.
> guid: c12839c4-9c29-11b1-9dad-c379636f7270
> direct instance of: #$AsymmetricBinaryPredicate

#$traversalTo traversal to **COMMENT NOT REVIEWED** **GAFs NOT REVIEWED**

> (#$traversalTo TRAV POINT) means that POINT is an ending point of the #$Traversal TRAV along some paths. Note that (#$traversalTo TRAV A) and (#$traversalTo TRAV B) may both be true even when A and B are different. This can happen when, e.g., A is a part of B and a path goes to both. This is why we did not call POINT, in the context above, THE ending point of TRAV.
> guid: bf8aaa38-9c29-11b1-9dad-c379636f7270
> direct instance of: #$AsymmetricBinaryPredicate

#$pointOnTraversal point on traversal **COMMENT NOT REVIEWED** **GAFs NOT REVIEWED**

> (#$pointOnTraversal A TRAV) means that A is a point along a #$Traversal TRAV of some path or paths. Let TRAV be (#$TraversalFn (#$TheList X(1) PATH(1) ... X(n) PATH(n) X(n+1))), using a #$PathChain to describe the traversal. Then (#$pointOnTraversal A TRAV) holds if and only if there is a k = 1, ..., n such that (#$pointOnPath-Generic A PATH(k)). Note that each PATH(k) is an instance of #$Path-Generic. See also #$Traversal and #$TraversalFn.
> guid: bede2c8d-9c29-11b1-9dad-c379636f7270
> direct instance of: #$AsymmetricBinaryPredicate
> direct specialization of: #$onTraversal

#$subTraversals sub traversals

> (#$subTraversals TRAV SUBTRAV) means that every point on the #$Traversal SUBTRAV (see the predicate #$pointOnTraversal) is also on the #$Traversal TRAV.
> guid: beaaeacb-9c29-11b1-9dad-c379636f7270
> direct instance of: #$AntiSymmetricBinaryPredicate #$ReflexiveBinaryPredicate #$TransitiveBinaryPredicate #$PartPredicate
> direct specialization of: #$parts

#$traversalFromToInSystem traversal from to in system **COMMENT NOT REVIEWED** **GAFs NOT REVIEWED**

> (#$traversalInSystem TRAV A B SYS) means that TRAV is a #$Traversal from A to B in the #$PathSystem SYS. Let TRAV = (#$TraversalFn (#$TheList X(1) PATH(1) ... X(n) PATH(n) X(n+1))). To say that TRAV is a #$Traversal from A to B in SYS we mean that (i) TRAV is a #$Traversal in SYS, i.e., (#$traversalInSystem TRAV SYS) holds, and (ii) A = X(1) and B = X(n+1) (and thus both A and B are points in SYS and both (#$traversalFrom TRAV A) and (#$traversalTo TRAV B) hold). So (#$traversalInSystem TRAV A B SYS) is actually an abbreviation of (#$and (#$traversalInSystem TRAV SYS) (#$pointInSystem A SYS) (#$pointInSystem B SYS) (#$traversalFrom TRAV A) (#$traversalTo TRAV B)).
> guid: c0082312-9c29-11b1-9dad-c379636f7270
> direct instance of: #$QuaternaryPredicate

#$traverses-Complete traversed path **COMMENT NOT REVIEWED** **GAFs NOT REVIEWED**

> (#$traverses-Complete MOVE TRAVER) means that the #$Movement-TranslationEvent MOVE traverses a path or series of paths (#$Path-Generics forming the #$Traversal TRAVER) during its motion, and that TRAVER is the entire traversal from beginning to end of the movement. The traversal may cross itself, go back and forth along the same path, or repeat cycles of paths (unlike the #$ActorSlot #$motionPathway-Complete, which can follow only one, non-self-crossing, pre-existing #$Path-Generic.) See also #$traverses-Partial. Contrast #$traverses-Complete with #$motionPathway-Complete, that relates to one existing #$Path-Generic, and with #$trajectory-Complete that relates to the pure #$Trajectory of the motion.
> guid: bf784989-9c29-11b1-9dad-c379636f7270
> direct instance of: #$AsymmetricBinaryPredicate #$BinaryRolePredicate
> direct specialization of: #$translationAlong #$traverses-Partial

#$traverses-Partial partially traversed path

> (#$traverses-Partial MOVE TRAV) means that the moving object OBJ in the #$Translation-SingleTrajectory MOVE (see #$objectMoving) is partially confined to the #$Traversal TRAV during MOVE. To say that OBJ is partially confined to TRAV during MOVE, we mean that (1) there is a subevent SUBEVENT of MOVE such that (#$subTranslations-SingleTrajectory MOVE SUBEVENT) holds, and (2) there is a sub-Traversal SUBTRAV of TRAV (see #$subTraversals) such that SUBEVENT is confined to SUBTRAV, i.e., (#$traverses-Complete SUBEVENT SUBTRAV) holds.
> guid: bd5f8e0a-9c29-11b1-9dad-c379636f7270
> direct instance of: #$BinaryRolePredicate #$AsymmetricBinaryPredicate
> direct specialization of: #$spatiallyRelated

#$traversalPassesThrough traversal passes through **COMMENT NOT REVIEWED** **GAFs NOT REVIEWED**

> (#$traversalPassesThrough TRAV POINT) means that POINT is a point that the #$Traversal TRAV passes through. Note that when TRAV passes through POINT, POINT cannot be a mere endpoint of TRAV. This means that a traversal does not pass through its starting point if it does not go back to the point and then leave it, nor does it pass through its ending point if it does not meet the point twice.
> guid: c14db0b9-9c29-11b1-9dad-c379636f7270
> direct instance of: #$AsymmetricBinaryPredicate

#$traversalInSystem traversal in system **COMMENT NOT REVIEWED** **GAFs NOT REVIEWED**

> (#$traversalInSystem TRAV SYS) means that TRAV is a #$Traversal of some paths in the #$PathSystem SYS. Let TRAV be represented by (#$TraversalFn (#$TheList X(1) PATH(1) ... X(n) PATH(n) X(n+1))). To say that TRAV is a #$Traversal in SYS we mean that (i) TRAV is a #$Traversal (and thus (#$TheList X(1) PATH(1) ... X(n) PATH(n) X(n+1)) is a #$PathChain), and (ii) each X(k) is a point in SYS and each PATH(k) is either a link or a loop in SYS, or a subpath of a loop in SYS. Our favorite description of a traversal in SYS is such a list that all X(k) are nodes in SYS except X(1) and X(n+1), and all PATH(k)s are links or loops in SYS except PATH(1) and PATH(n).
> guid: c153824c-9c29-11b1-9dad-c379636f7270
> direct instance of: #$AsymmetricBinaryPredicate

#$traversalInSystem-OrderObserved traversal in system - order observed

> (#$traversalInSystem-OrderObserved TRAV SYS) means that TRAV is a #$Traversal of some paths in the #$Semi-DirectedPathSystem SYS, and that TRAV observes the orders or directions of links (and paths) in SYS. To say that TRAV observes the orders or directions of links in SYS, we mean that for each link LINK in SYS between X and Y, (#$TraversalFn (#$TheList X LINK Y)) is a subtraversal of TRAV only if (#$linkFromToInSystem LINK X Y SYS) holds, and for each subpath SUB between A and B of a link LINK in SYS between X and Y, (#$TraversalFn (#$TheList A SUB B)) is a subtraversal of TRAV only if (#$linkFromToInSystem LINK X Y SYS) holds.
> guid: bf4688ba-9c29-11b1-9dad-c379636f7270
> direct instance of: #$AsymmetricBinaryPredicate
> direct specialization of: #$traversalInSystem

#$SubSystemUnderTraversalFn sub system under traversal fn **COMMENT NOT REVIEWED** **GAFs NOT REVIEWED**

> A function, when applied to a #$PathSystem SYS and a #$Traversal TRAV in SYS as in (#$SubSystemUnderTraversalFn SYS TRAV), returns the smallest point-closed subsystem SUB of SYS such that TRAV is a traversal in SUB (see #$smallestSubSystemUnderTraversal, #$traversalInSystem and #$pointClosedSubSystems). Note that 'smallest' here means that no link LINK between X and Y in SYS is a link in SUB if neither (#$TraversalFn (#$TheList X LINK Y)) nor (#$TraversalFn (#$TheList Y LINK X)) is a #$subTraversals of TRAV. Note also that since SUB is a point-closed subsystem of SYS, every point in SYS that is on TRAV (see #$pointOnTraversal) is a point in SUB. Note finally that since SUB is the 'smallest' subsystem of SYS in which TRAV is a traversal, SUB must be a #$ConnectedPathSystem.
> guid: c10af9e3-9c29-11b1-9dad-c379636f7270
> direct instance of: #$BinaryFunction #$Individual

### A Few Examples Of Customary Paths

#$Pipe-GenericConduit pipes

> A specialization of #$FluidConduit; the collection of all enclosed tubular fluid conduits with openings at both ends. #$Pipe-GenericConduit encompasses both human-made pipes as well as natural pipes, found naturally occurring in the environment or in an organism's body (like #$BloodVessels).
> guid: bd5899fd-9c29-11b1-9dad-c379636f7270
> direct instance of: #$ExistingObjectType
> direct specialization of: #$CylindricalHollowObject #$Container #$FluidConduit
> direct generalization of: #$AnatomicalVessel

#$Railway railroads

> #$Railway is a specialization of #$TransportFacility and #$PathForWheeledVehicles. Each instance of #$Railway is a pathway made of railroad tracks and used for train transportation. It includes main lines and sidings.
> guid: bd58be94-9c29-11b1-9dad-c379636f7270
> direct instance of: #$PathType #$ExistingObjectType
> direct specialization of: #$TransportFacility #$PathForWheeledVehicles
> direct generalization of: #$Subway

#$Highway highways

> A specialization of both #$Roadway and #$PublicProperty. Each instance of #$Highway is a major road open to public use.
> guid: bd58d561-9c29-11b1-9dad-c379636f7270
> direct instance of: #$ExistingObjectType
> direct specialization of: #$Path-Simple #$Roadway

#$Stream streams (fresh water) (ecological regions) (bodies of water)

> A specialization of #$Water-Fresh, #$InanimateThing-Natural, and #$FlowPath. Each instance of #$Stream is a natural body of fresh water that flows when it is not frozen. A stream can either be a great river (see #$River) or a tiny creek (see #$Creek). Every non-frozen stream flows in (see #$in-ContOpen) some conduit (see #$FluidConduit) such as a streambed or riverbed. Notable instances of #$Stream incluide #$AmazonRiver, #$LittleMissouriRiver, #$WoundedKnee-Creek. Note that riverbanks are not streams nor are they parts of streams, but rather they mark the edges of streams.
> guid: bd590774-9c29-11b1-9dad-c379636f7270
> direct instance of: #$ExistingObjectType
> direct specialization of: #$Water-Fresh #$InanimateThing-Natural #$BodyOfWater #$FlowPath #$EcologicalRegion
> direct generalization of: #$River

### Trajectories Of Moving Things

#$Trajectory trajectories **COMMENT NOT REVIEWED** **GAFs NOT REVIEWED**

> The collection of all trajectories of moving objects: each instance of #$Trajectory is the individual spatial region consisting of the points in space through which an object passes during a #$Movement-TranslationEvent. A trajectory may or may not follow some pre-existing or pre-defined path (#$Path-Generic). If it does follow one or more such paths, it determines a #$Traversal of those paths. A #$Trajectory is understood and defined as a spatial line with one of the two possible directions of motion along it. It is considered as being a part of some stationary background space (thus, in most contexts, a #$Trajectory cannot itself 'move'). Unlike a #$Path-Generic, a #$Trajectory (or a #$Traversal) can cross itself any number of times, and go back along itself, cycle over and over again, etc. If there is a #$Movement-TranslationEvent, then that event always has a #$Trajectory; it is linked to its #$Trajectory by the #$ActorSlots #$trajectory-Complete and possibly #$trajectory-Partial. In most contexts, a #$Trajectory will be a line (or rather a one-manifold) through space as traced by some designated point within the moving object (e.g., the center of gravity), but the collection #$Trajectory-SweptSpace is available to represent the whole space (with space and thickness) swept through by a moving object. Contrast #$Trajectory with #$Path-Generic and with #$Traversal.
> guid: bd58d17a-9c29-11b1-9dad-c379636f7270
> direct instance of: #$ObjectType
> direct specialization of: #$SpatialThing-Localized #$IntangibleExistingThing

#$Trajectory-SweptSpace trajectory swept space **COMMENT NOT REVIEWED** **GAFs NOT REVIEWED**

> The collection of all spatial regions that are defined as the precise regions swept through by trajectories of moving objects: each instance of #$Trajectory-SweptSpace is the individual spatial region consisting of all the points in space through which an object (or any part of it) passes during a #$Movement-TranslationEvent. A #$Trajectory-SweptSpace may or may not follow some pre-existing or pre-defined path (#$Path-Generic). If it does follow one or more such paths, it determines a #$Traversal of those paths. A #$Trajectory-SweptSpace is understood and defined as a spatial region (often long, thin and 'worm'-shaped) with one of the two possible directions of motion along it. It is considered as being a part of some stationary background space (thus, in most contexts, a #$Trajectory-SweptSpace cannot itself 'move'). Unlike a #$Path-Generic, a #$Trajectory-SweptSpace (or a #$Traversal) can cross itself any number of times, intersect itself, go back along itself, cycle over and over again, etc. If there is a #$Movement-TranslationEvent, then that event always has a #$Trajectory-SweptSpace; it contains within it the linear #$Trajectory of the motion, (indicated using #$trajectory-Complete or possibly #$trajectory-Partial). In most contexts, a #$Trajectory will be a line (or rather a one-manifold) through space as traced by some designated point within the moving object (e.g., the center of gravity), but the #$Trajectory-SweptSpace is available to represent the whole space (with space and thickness) swept through by a moving object. Contrast #$Trajectory-SweptSpace with #$Path-Generic and with #$Traversal.
> guid: c146c43f-9c29-11b1-9dad-c379636f7270
> direct instance of: #$ObjectType
> direct specialization of: #$SpatialThing-Localized

#$trajectory-Complete path of motion **COMMENT NOT REVIEWED** **GAFs NOT REVIEWED**

> (#$trajectory-Complete MOVE TRAJ) means that the #$Movement-TranslationEvent MOVE has the #$Trajectory TRAJ as its entire trajectory. Suppose OBJ is the #$objectMoving in TRAJ. TRAJ is a line or curve in space (technically a one-manifold) traced out by some reference point (probably the centroid) of OBJ. See also #$trajectory-Partial. Contrast #$trajectory-Complete with #$motionPathway-Complete and with #$traverses-Complete. The trajectory of the motion may cross itself, zig-zag back and forth along the same path, repeat several cycles, etc., and the trajectory need not be confined to any pre-existing #$Path-Generics or #$Traversals of paths.
> guid: bff60f8e-9c29-11b1-9dad-c379636f7270
> direct instance of: #$ActorSlot
> direct specialization of: #$trajectory-Partial #$eventOccursAt

#$trajectory-Partial trajectory - partial **COMMENT NOT REVIEWED** **GAFs NOT REVIEWED**

> (#$trajectory-Partial MOVE TRAJ) means that the #$Movement-TranslationEvent MOVE has at least part of its entire trajectory, i.e., the line or curve in space traced out by the whole motion, in common with a sub-trajectory of the #$Trajectory TRAJ where the motion along the shared segment moves in the same direction as TRAJ goes. See also #$trajectory-Complete. Contrast #$trajectory-Partial with #$motionPathway-Partial and with #$traverses-Partial. The trajectory of the motion may cross itself, zig-zag back and forth along the same path, repeat several cycles, etc., (like a #$Traversal and unlike a #$Path-Generic), and the trajectory need not be confined to any pre-existing #$Path-Generics or #$Traversals of paths.
> guid: be082c6d-9c29-11b1-9dad-c379636f7270
> direct instance of: #$ActorSlot
> direct specialization of: #$actors

#$trajectoryPassesThrough thing passed through (actor slot) (role) (extensional representation predicate) **COMMENT NOT REVIEWED** **GAFs NOT REVIEWED**

> (#$trajectoryPassesThrough MOVE LOC) means that the #$trajectory-Complete of the #$Translation-SingleTrajectory MOVE passes through LOC, which is an instance of #$SpatialThing-Localized, and thus can be a location, a portal, a river, a path, the equator, etc. More formally, the #$objectMoving which undergoes MOVE from the #$fromLocation to the #$toLocation passes through LOC. Here `passes through LOC' means that the #$objectMoving OBJ both arrives in and leaves LOC. Thus, LOC can not be a super region of any #$fromLocation nor any #$toLocations of MOVE. Otherwise it would be possible to state (#$trajectoryPassesThrough TripToTheStore01 TheUniverse). On the other hand, LOC can be a sub region of some #$toLocation or some #$fromLocation.
> guid: bfd6faea-9c29-11b1-9dad-c379636f7270
> direct instance of: #$ActorSlot
> direct specialization of: #$nonDeliberateActors

#$TrajectoryThroughAir trajectory through air **COMMENT NOT REVIEWED** **GAFs NOT REVIEWED**

> The collection of all trajectories of objects moving through air (mid-air). Such a #$Trajectory exists as the #$trajectory-Complete for any #$Movement-TranslationEvent all of which passes through mid-air. This includes arbitrary traces through the air. A #$TrajectoryThroughAir may or may not follow a designated or pre-defined #$PathThroughAir. The moving object is immersed in, and supported, if supported at all, by the air. Thus it excludes a #$SolidSurfaceTrajectoryThroughAir and a #$WaterSurfaceTrajectory. For a pre-designated #$Path-Generic through airspace, use #$PathThroughAir.
> guid: be008b2c-9c29-11b1-9dad-c379636f7270
> direct instance of: #$ObjectType
> direct specialization of: #$Trajectory

#$SolidSurfaceTrajectoryThroughAir solid surface trajectory through air **COMMENT NOT REVIEWED** **GAFs NOT REVIEWED**

> The collection of all trajectories of motions that pass through air along a solid surface. Any #$objectMoving following such a #$Trajectory (see #$trajectory-Partial) is immersed in the air but supported by the solid surface. Examples: a person walking on a sidewalk, or a bug crawling up a wall.
> guid: c1110dea-9c29-11b1-9dad-c379636f7270
> direct instance of: #$ObjectType
> direct specialization of: #$Trajectory

#$TrajectoryThroughSolid trajectory through solid **COMMENT NOT REVIEWED** **GAFs NOT REVIEWED**

> The collection of all tajectories of motions through solid material. The trajectory traced by a burrowing animal, or a neutrino trajectory through the Earth, would be examples. Boring into wood and burrowing through the earth are locomotions whose trajectories may or may not follow designated paths. For a designated or pre-existing path through a solid, (not just a #$Trajectory of some motion), use #$PathThroughSolid.
> guid: bed48777-9c29-11b1-9dad-c379636f7270
> direct instance of: #$ObjectType
> direct specialization of: #$Trajectory

#$TrajectoryThroughWater trajectory through water **COMMENT NOT REVIEWED** **GAFs NOT REVIEWED**

> The collection of all trajectories of underwater motions (#$Movement-TranslationEvents that go entirely through water). An #$objectMoving with such a #$Trajectory is immersed in, and supported by, the water. Thus it excludes a #$SolidSurfaceTrajectoryThroughWater and a #$WaterSurfaceTrajectory. For pre-designated or customary #$Path-Generics through water (e.g. submarine designated paths, sea lanes and corridors), use #$PathThroughWater. For trajectories of objects floating on the surface, use #$WaterSurfaceTrajectory.
> guid: bf874177-9c29-11b1-9dad-c379636f7270
> direct instance of: #$ObjectType
> direct specialization of: #$Trajectory

#$WaterSurfaceTrajectory water surface trajectory **COMMENT NOT REVIEWED** **GAFs NOT REVIEWED**

> The collection of all trajectories of movements across the surfaces of bodies of water. Each such #$Trajectory is traced out by the motion of the object along a water surface. A moving object with a #$WaterSurfaceTrajectory is supported by the water, but is neither fully immersed in the water nor completely in the air. The trajectory may or may not follow designated #$WaterSurfacePaths like sea-lanes, channels, pre-designated ship routes, safe-passage mine-free paths, etc. For a pre-designated or pre-existing #$Path-Generic across a water surface, use #$WaterSurfacePath.
> guid: bedf10e0-9c29-11b1-9dad-c379636f7270
> direct instance of: #$ObjectType
> direct specialization of: #$Trajectory

#$SolidSurfaceTrajectoryThroughWater solid surface trajectory through water **COMMENT NOT REVIEWED** **GAFs NOT REVIEWED**

> The collection of all trajectories of motions that pass through water but along a solid surface. Any #$objectMoving following such a #$Trajectory (see #$trajectory-Partial) is immersed in water but supported by the solid surface. Examples: the trajectory of a crab walking along the sea bottom, or of an undersea exploration robot, or of a snail crawling up inside the glass of an aquarium. For designated or pre-existing #$Path-Generics that are situated in water along a solid, use #$SolidSurfacePathThroughWater.
> guid: c12ade02-9c29-11b1-9dad-c379636f7270
> direct instance of: #$ObjectType
> direct specialization of: #$Trajectory

Copyright© 1996-2002. All rights reserved. See Terms of Usage.