pycrap.ontologies

pycrap.ontologies#

Submodules#

Attributes#

`ontology_file`
`ontology`
`CRAX_ONTOLOGY_NAME`
`ontology_file`
`ontology`
`CRAX_ONTOLOGY_NAME`

Classes#

`Base`
`BaseProperty`
`BaseDatatype`
`World`	The world could be the belief state of an agent about the world.
`Floor`	The floor of the world.
`Milk`	A milk carton.
`Robot`	The robot.
`Cereal`	A cereal box.
`Kitchen`	A kitchen.
`Food`
`Fruit`
`Apple`
`Environment`
`Apartment`
`Cup`
`Spoon`
`Bowl`
`PreferredGraspAlignment`
`XAxis`
`YAxis`
`NoAlignment`
`Truthy`
`Falsy`
`Cabinet`
`Washer`
`Drawer`
`Refrigerator`
`Sink`
`Door`
`Cutting`
`Pouring`
`Handle`
`Link`
`PhysicalObject`
`PouringTool`	The Tool that is used for pouring, can be cup, bottle, etc.
`CuttingTool`	The tool used for cutting — such as a knife, bread-knife, or similar — depends on the specific task and object being processed.
`MixingTool`	The tool used for mixing — such as a Spoon, Whisk, or similar — depends on the specific task and object being processed.
`Agent`
`Human`
`Room`
`Location`
`Container`
`Joint`
`ContinuousJoint`	A continuous hinge joint that rotates around an axis and has no upper and lower limits.
`HingeJoint`	A joint that rotates along an axis.
`FixedJoint`	A joint that cannot move, designed to fixiate links.
`MovableJoint`	A joint where the two connected links can move relative to each other in some dimension.
`FloatingJoint`	A joint that allows motion for all 6 degrees of freedom.
`PlanarJoint`	A joint that allows motion in a plane perpendicular to an axis.
`PrismaticJoint`	A sliding joint that slides along an axis, and has a limited range specified by the upper and lower limits.
`RevoluteJoint`	A hinge joint that rotates along an axis and has a limited range specified by the upper and lower limits.
`DesignedFurniture`	An object used to make a room or building suitable for living or working.
`Surface`	The outside part or uppermost layer of something.
`PhysicalTask`	A task in which a PhysicalAgent affects some physical object.
`Action`	An Event with at least one Agent that isParticipantIn it, and that executes a Task that typically isDefinedIn a Plan, Workflow, Project, etc.
`Event`	Any physical, social, or mental process, event, or state.
`Entity`	Anything: real, possible, or imaginary, which some modeller wants to talk about for some purpose.
`Task`	An EventType that classifies an Action to be executed.
`RootLink`
`Supporter`	A physical object that supports another object.
`SupportedObject`	A physical object that is supported by another object.
`Base`
`BaseProperty`
`BaseDatatype`
`is_part_of`	A relation between any entities, e.g. 'brain is a part of the human body'. See dul:hasPart for additional documentation.
`has_part`	A schematic relation between any entities, e.g. 'the human body has a brain as part', '20th century contains year 1923', 'World War II includes the Pearl Harbour event'.
`has_parent_link`	Relates a joint to the link it connects which is closer to the root of the kinematic chain.
`has_child_link`	Relates a joint to the link it connects which is closer to the end of the kinematic chain.
`contains`	A schematic relation asserting containment, understood in a very broad sense, by one Entity of another.
`contains_object`	A spatial relation holding between a container, and objects it contains.
`is_contained_in`	The inverse of the contains relation. See the contains relation for details.
`has_preferred_alignment`	A relation between an object and an alignment that is preferred for that object.
`has_preferred_axis`	A relation between an object and an axis identifier.
`has_vertical_alignment`	A relation between an object and boolean value indicating if the object should be grasped with a vertical alignment.
`has_rotated_gripper`	A relation between an object and boolean value indicating if the gripper should be rotated by 90°.
`has_rim_grasp`	A relation between an object and a boolean value indicating if the object should be grasped by the rim.
`is_physically_contained_in`	A spatial relation holding between an object (the container), and objects it contains.
`supports`	A relation between an object (the supporter) and another object (the supportee) where the supporter cancels the
`is_supported_by`	A relation between an object (the supporter) and another object (the supportee) where the supporter cancels the
`BowlPreferredGraspAlignment`
`DefaultPreferredGraspAlignment`
`SpoonPreferredGraspAlignment`
`CerealPreferredGraspAlignment`

Package Contents#

pycrap.ontologies.ontology_file#

pycrap.ontologies.ontology#

pycrap.ontologies.CRAX_ONTOLOGY_NAME = 'PyCRAP'#

class pycrap.ontologies.Base#

Bases: owlready2.Thing

namespace#

class pycrap.ontologies.BaseProperty#

Bases: owlready2.ObjectProperty

namespace#

class pycrap.ontologies.BaseDatatype#

Bases: owlready2.DatatypeProperty

namespace#

class pycrap.ontologies.World#

Bases: Base

The world could be the belief state of an agent about the world.

class pycrap.ontologies.Floor#

Bases: Base

The floor of the world.

class pycrap.ontologies.Milk#

Bases: Base

A milk carton.

class pycrap.ontologies.Robot#

Bases: Base

The robot.

class pycrap.ontologies.Cereal#

Bases: Base

A cereal box.

class pycrap.ontologies.Kitchen#

Bases: Base

A kitchen.

class pycrap.ontologies.Food#: Bases: Base

class pycrap.ontologies.Fruit#: Bases: Food

class pycrap.ontologies.Apple#: Bases: Fruit

class pycrap.ontologies.Environment#: Bases: Base

class pycrap.ontologies.Apartment#: Bases: Environment

class pycrap.ontologies.Cup#: Bases: Base

class pycrap.ontologies.Spoon#: Bases: Base

class pycrap.ontologies.Bowl#: Bases: Base

class pycrap.ontologies.PreferredGraspAlignment#: Bases: Base

class pycrap.ontologies.XAxis#

Bases: Base

value = (1, 0, 0)#

class pycrap.ontologies.YAxis#

Bases: Base

value = (0, 1, 0)#

class pycrap.ontologies.NoAlignment#

Bases: Base

value = (0, 0, 0)#

class pycrap.ontologies.Truthy#

Bases: Base

value = True#

class pycrap.ontologies.Falsy#

Bases: Base

value = False#

class pycrap.ontologies.Cabinet#: Bases: Base

class pycrap.ontologies.Washer#: Bases: Base

class pycrap.ontologies.Drawer#: Bases: Base

class pycrap.ontologies.Refrigerator#: Bases: Base

class pycrap.ontologies.Sink#: Bases: Base

class pycrap.ontologies.Door#: Bases: Base

class pycrap.ontologies.Cutting#: Bases: Base

class pycrap.ontologies.Pouring#: Bases: Base

class pycrap.ontologies.Handle#: Bases: Base

class pycrap.ontologies.Link#: Bases: Base

class pycrap.ontologies.PhysicalObject#: Bases: Base

class pycrap.ontologies.PouringTool#

Bases: PhysicalObject

The Tool that is used for pouring, can be cup, bottle, etc.

class pycrap.ontologies.CuttingTool#

Bases: PhysicalObject

The tool used for cutting — such as a knife, bread-knife, or similar — depends on the specific task and object being processed.

class pycrap.ontologies.MixingTool#

Bases: PhysicalObject

The tool used for mixing — such as a Spoon, Whisk, or similar — depends on the specific task and object being processed.

class pycrap.ontologies.Agent#: Bases: Base

class pycrap.ontologies.Human#: Bases: Base

class pycrap.ontologies.Room#: Bases: Base

class pycrap.ontologies.Location#: Bases: Base

class pycrap.ontologies.Container#: Bases: Base

class pycrap.ontologies.Joint#: Bases: Base

class pycrap.ontologies.ContinuousJoint#

Bases: Base

A continuous hinge joint that rotates around an axis and has no upper and lower limits.

class pycrap.ontologies.HingeJoint#

Bases: Base

A joint that rotates along an axis.

class pycrap.ontologies.FixedJoint#

Bases: Base

A joint that cannot move, designed to fixiate links.

class pycrap.ontologies.MovableJoint#

Bases: Base

A joint where the two connected links can move relative to each other in some dimension.

class pycrap.ontologies.FloatingJoint#

Bases: Base

A joint that allows motion for all 6 degrees of freedom.

class pycrap.ontologies.PlanarJoint#

Bases: Base

A joint that allows motion in a plane perpendicular to an axis.

class pycrap.ontologies.PrismaticJoint#

Bases: Base

A sliding joint that slides along an axis, and has a limited range specified by the upper and lower limits.

class pycrap.ontologies.RevoluteJoint#

Bases: Base

A hinge joint that rotates along an axis and has a limited range specified by the upper and lower limits.

class pycrap.ontologies.DesignedFurniture#

Bases: Base

An object used to make a room or building suitable for living or working.

class pycrap.ontologies.Surface#

Bases: Base

The outside part or uppermost layer of something.

class pycrap.ontologies.PhysicalTask#

Bases: Base

A task in which a PhysicalAgent affects some physical object.

class pycrap.ontologies.Action#

Bases: Base

An Event with at least one Agent that isParticipantIn it, and that executes a Task that typically isDefinedIn a Plan, Workflow, Project, etc.

class pycrap.ontologies.Event#

Bases: Base

Any physical, social, or mental process, event, or state.

More theoretically, events can be classified in different ways, possibly based on ‘aspect’ (e.g. stative, continuous, accomplishement, achievement, etc.), on ‘agentivity’ (e.g. intentional, natural, etc.), or on ‘typical participants’ (e.g. human, physical, abstract, food, etc.). Here no special direction is taken, and the following explains why: events are related to observable situations, and they can have different views at a same time. If a position has to be suggested here anyway, the participant-based classification of events seems the most stable and appropriate for many modelling problems.

Alternative aspectual views

Consider a same event ‘rock erosion in the Sinni valley’: it can be conceptualized as an accomplishment (what has brought a certain state to occur), as an achievement (the state resulting from a previous accomplishment), as a punctual event (if we collapse the time interval of the erosion into a time point), or as a transition (something that has changed from a state to a different one). In the erosion case, we could therefore have good motivations to shift from one aspect to another: a) causation focus, b) effectual focus, c) historical condensation, d) transition (causality).

The different views refer to the same event, but are still different: how to live with this seeming paradox? A typical solution e.g. in linguistics (cf. Levin’s aspectual classes) and in DOLCE Full (cf. WonderWeb D18 axiomatization) is to classify events based on aspectual differences. But this solution would create different identities for a same event, where the difference is only based on the modeller’s attitude. An alternative solution is suggested here, and exploits the notion of (observable) Situation; a Situation is a view, consistent with a Description, which can be observed of a set of entities. It can also be seen as a ‘relational context’ created by an observer on the basis of a ‘frame’. Therefore, a Situation allows to create a context where each particular view can have a proper identity, while the Event preserves its own identity. For example, ErosionAsAccomplishment is a Situation where rock erosion is observed as a process leading to a certain achievement: the conditions (roles, parameters) that suggest such view are stated in a Description, which acts as a ‘theory of accomplishments’. Similarly, ErosionAsTransition is a Situation where rock erosion is observed as an event that has changed a state to another: the conditions for such interpretation are stated in a different Description, which acts as a ‘theory of state transitions’. Consider that in no case the actual event is changed or enriched in parts by the aspectual view.

Alternative intentionality views

Similarly to aspectual views, several intentionality views can be provided for a same Event. For example, one can investigate if an avalanche has been caused by immediate natural forces, or if there is any hint of an intentional effort to activate those natural forces. Also in this case, the Event as such has not different identities, while the causal analysis generates situations with different identities, according to what Description is taken for interpreting the Event. On the other hand, if the possible actions of an Agent causing the starting of an avalanche are taken as parts of the Event, then this makes its identity change, because we are adding a part to it. Therefore, if intentionality is a criterion to classify events or not, this depends on if an ontology designer wants to consider causality as a relevant dimension for events’ identity.

Alternative participant views

A slightly different case is when we consider the basic participants to an Event. In this case, the identity of the Event is affected by the participating objects, because it depends on them. For example, if snow, mountain slopes, wind, waves, etc. are considered as an avalanche basic participants, or if we also want to add water, human agents, etc., that makes the identity of an avalanche change. Anyway, this approach to event classification is based on the designer’s choices, and more accurately mirrors lexical or commonsense classifications (see. e.g. WordNet ‘supersenses’ for verb synsets).

Ultimately, this discussion has no end, because realists will keep defending the idea that events in reality are not changed by the way we describe them, while constructivists will keep defending the idea that, whatever ‘true reality’ is about, it can’t be modelled without the theoretical burden of how we observe and describe it. Both positions are in principle valid, but, if taken too radically, they focus on issues that are only partly relevant to the aim of computational ontologies, which assist domain experts in representing a certain portion of reality according to their own assumptions and requirements.

For this reason, in this ontology version of DOLCE, both events and situations are allowed, together with descriptions (the reason for the inclusion of the D&S framewrok in DOLCE), in order to encode the modelling needs, independently from the position (if any) chosen by the model designer.

class pycrap.ontologies.Entity#

Bases: Base

Anything: real, possible, or imaginary, which some modeller wants to talk about for some purpose.

class pycrap.ontologies.Task#

Bases: Base

An EventType that classifies an Action to be executed. For example, reaching a destination is a task that can be executed by performing certain actions, e.g. driving a car, buying a train ticket, etc. The actions to execute a task can also be organized according to a Plan that is not the same as the one that defines the task (if any). For example, reaching a destination could be defined by a plan to get on holidays, while the plan to execute the task can consist of putting some travels into a sequence.

class pycrap.ontologies.RootLink#: Bases: Base

class pycrap.ontologies.Supporter#

Bases: Base

A physical object that supports another object.

class pycrap.ontologies.SupportedObject#

Bases: Base

A physical object that is supported by another object.

pycrap.ontologies.ontology_file#

pycrap.ontologies.ontology#

pycrap.ontologies.CRAX_ONTOLOGY_NAME = 'PyCRAP'#

class pycrap.ontologies.Base#

Bases: owlready2.Thing

namespace#

class pycrap.ontologies.BaseProperty#

Bases: owlready2.ObjectProperty

namespace#

class pycrap.ontologies.BaseDatatype#

Bases: owlready2.DatatypeProperty

namespace#

class pycrap.ontologies.is_part_of#

Bases: BaseProperty

A relation between any entities, e.g. ‘brain is a part of the human body’. See dul:hasPart for additional documentation.

class pycrap.ontologies.has_part#

Bases: BaseProperty

A schematic relation between any entities, e.g. ‘the human body has a brain as part’, ‘20th century contains year 1923’, ‘World War II includes the Pearl Harbour event’.

Parthood should assume the basic properties of mereology: transitivity, antisymmetry, and reflexivity (propert Parthood of course misses reflexivity). However, antisymmetry is not supported in OWL2 explicitly, therefore DUL has to adopt one of two patterns: 1) dropping asymmetry axioms, while granting reflexivity: this means that symmetry is not enforced, but permitted for the case of reflexivity. Of course, in this way we cannot prevent symmetric usages of hasPart; 2) dropping the reflexivity axiom, and enforce asymmetry: in this case, we would prevent all symmetric usages, but we loose the possibility of enforcing reflexivity, which is commonsensical in parthood. In DUL, we adopt pattern #1 for partOf, and pattern #2 for properPartOf, which seems a good approximation: due to the lack of inheritance of property characteristics, each asymmetric hasPropertPart assertion would also be a reflexive hasPart assertion (reflexive reduction design pattern).

Subproperties and restrictions can be used to specialize hasPart for objects, events, etc.

class pycrap.ontologies.has_parent_link#

Bases: BaseProperty

Relates a joint to the link it connects which is closer to the root of the kinematic chain.

class pycrap.ontologies.has_child_link#

Bases: BaseProperty

Relates a joint to the link it connects which is closer to the end of the kinematic chain.

class pycrap.ontologies.contains#

Bases: BaseProperty

A schematic relation asserting containment, understood in a very broad sense, by one Entity of another. The relation is defined with domain and range of maximum generality, as it is possible to construe containment to apply between Events, between Objects, between Qualities and so on. Care should be taken when using it that the construal of containment makes sense and is useful. If a clearer relation expresses the connection between two Entities, use that relation instead. For example, rather than saying an Event contains an Object, it is probably better to say the Event has that Object as a participant. More specific versions of this relation exist, e.g. containsEvent, so it is likely that there will be few situations where it should be used itself. However, by acting as a superproperty to several relations, it captures a core similarity between these and enables taxonomy-based similarity metrics.

class pycrap.ontologies.contains_object#

Bases: BaseProperty

A spatial relation holding between a container, and objects it contains.

class pycrap.ontologies.is_contained_in#

Bases: BaseProperty

The inverse of the contains relation. See the contains relation for details.

class pycrap.ontologies.has_preferred_alignment#

Bases: BaseProperty

A relation between an object and an alignment that is preferred for that object.

class pycrap.ontologies.has_preferred_axis#

Bases: BaseProperty

A relation between an object and an axis identifier.

class pycrap.ontologies.has_vertical_alignment#

Bases: BaseProperty

A relation between an object and boolean value indicating if the object should be grasped with a vertical alignment.

class pycrap.ontologies.has_rotated_gripper#

Bases: BaseProperty

A relation between an object and boolean value indicating if the gripper should be rotated by 90°.

class pycrap.ontologies.has_rim_grasp#

Bases: BaseProperty

A relation between an object and a boolean value indicating if the object should be grasped by the rim.

class pycrap.ontologies.is_physically_contained_in#

Bases: BaseProperty

A spatial relation holding between an object (the container), and objects it contains.

class pycrap.ontologies.supports#

Bases: BaseProperty

A relation between an object (the supporter) and another object (the supportee) where the supporter cancels the: effect of gravity on the supportee.

class pycrap.ontologies.is_supported_by#

Bases: BaseProperty

A relation between an object (the supporter) and another object (the supportee) where the supporter cancels the: effect of gravity on the supportee. The inverse of the supports relation.

class pycrap.ontologies.BowlPreferredGraspAlignment#: Bases: pycrap.ontologies.crax.classes.PreferredGraspAlignment

class pycrap.ontologies.DefaultPreferredGraspAlignment#: Bases: pycrap.ontologies.crax.classes.PreferredGraspAlignment

class pycrap.ontologies.SpoonPreferredGraspAlignment#: Bases: pycrap.ontologies.crax.classes.PreferredGraspAlignment

class pycrap.ontologies.CerealPreferredGraspAlignment#: Bases: pycrap.ontologies.crax.classes.PreferredGraspAlignment