pycrap.ontologies.crax ====================== .. py:module:: pycrap.ontologies.crax Submodules ---------- .. toctree:: :maxdepth: 1 /autoapi/pycrap/ontologies/crax/classes/index /autoapi/pycrap/ontologies/crax/data_properties/index /autoapi/pycrap/ontologies/crax/dependencies/index /autoapi/pycrap/ontologies/crax/individuals/index /autoapi/pycrap/ontologies/crax/object_properties/index /autoapi/pycrap/ontologies/crax/restrictions/index /autoapi/pycrap/ontologies/crax/rules/index Attributes ---------- .. autoapisummary:: pycrap.ontologies.crax.ontology_file pycrap.ontologies.crax.ontology pycrap.ontologies.crax.CRAX_ONTOLOGY_NAME pycrap.ontologies.crax.ontology_file pycrap.ontologies.crax.ontology pycrap.ontologies.crax.CRAX_ONTOLOGY_NAME pycrap.ontologies.crax.ontology_file pycrap.ontologies.crax.ontology pycrap.ontologies.crax.CRAX_ONTOLOGY_NAME pycrap.ontologies.crax.ontology_file pycrap.ontologies.crax.ontology pycrap.ontologies.crax.CRAX_ONTOLOGY_NAME Classes ------- .. autoapisummary:: pycrap.ontologies.crax.World pycrap.ontologies.crax.Floor pycrap.ontologies.crax.Milk pycrap.ontologies.crax.Robot pycrap.ontologies.crax.Cereal pycrap.ontologies.crax.Kitchen pycrap.ontologies.crax.Food pycrap.ontologies.crax.Fruit pycrap.ontologies.crax.Apple pycrap.ontologies.crax.Environment pycrap.ontologies.crax.Apartment pycrap.ontologies.crax.Cup pycrap.ontologies.crax.Spoon pycrap.ontologies.crax.Bowl pycrap.ontologies.crax.PreferredGraspAlignment pycrap.ontologies.crax.XAxis pycrap.ontologies.crax.YAxis pycrap.ontologies.crax.NoAlignment pycrap.ontologies.crax.Truthy pycrap.ontologies.crax.Falsy pycrap.ontologies.crax.Cabinet pycrap.ontologies.crax.Washer pycrap.ontologies.crax.Drawer pycrap.ontologies.crax.Refrigerator pycrap.ontologies.crax.Sink pycrap.ontologies.crax.Door pycrap.ontologies.crax.Cutting pycrap.ontologies.crax.Pouring pycrap.ontologies.crax.Handle pycrap.ontologies.crax.Link pycrap.ontologies.crax.PhysicalObject pycrap.ontologies.crax.PouringTool pycrap.ontologies.crax.CuttingTool pycrap.ontologies.crax.MixingTool pycrap.ontologies.crax.Agent pycrap.ontologies.crax.Human pycrap.ontologies.crax.Room pycrap.ontologies.crax.Location pycrap.ontologies.crax.Container pycrap.ontologies.crax.Joint pycrap.ontologies.crax.ContinuousJoint pycrap.ontologies.crax.HingeJoint pycrap.ontologies.crax.FixedJoint pycrap.ontologies.crax.MovableJoint pycrap.ontologies.crax.FloatingJoint pycrap.ontologies.crax.PlanarJoint pycrap.ontologies.crax.PrismaticJoint pycrap.ontologies.crax.RevoluteJoint pycrap.ontologies.crax.DesignedFurniture pycrap.ontologies.crax.Surface pycrap.ontologies.crax.PhysicalTask pycrap.ontologies.crax.Action pycrap.ontologies.crax.Event pycrap.ontologies.crax.Entity pycrap.ontologies.crax.Task pycrap.ontologies.crax.RootLink pycrap.ontologies.crax.Supporter pycrap.ontologies.crax.SupportedObject pycrap.ontologies.crax.Base pycrap.ontologies.crax.BaseProperty pycrap.ontologies.crax.BaseDatatype pycrap.ontologies.crax.is_part_of pycrap.ontologies.crax.has_part pycrap.ontologies.crax.has_parent_link pycrap.ontologies.crax.has_child_link pycrap.ontologies.crax.contains pycrap.ontologies.crax.contains_object pycrap.ontologies.crax.is_contained_in pycrap.ontologies.crax.has_preferred_alignment pycrap.ontologies.crax.has_preferred_axis pycrap.ontologies.crax.has_vertical_alignment pycrap.ontologies.crax.has_rotated_gripper pycrap.ontologies.crax.has_rim_grasp pycrap.ontologies.crax.is_physically_contained_in pycrap.ontologies.crax.supports pycrap.ontologies.crax.is_supported_by pycrap.ontologies.crax.Base pycrap.ontologies.crax.BaseProperty pycrap.ontologies.crax.BaseDatatype pycrap.ontologies.crax.BowlPreferredGraspAlignment pycrap.ontologies.crax.DefaultPreferredGraspAlignment pycrap.ontologies.crax.SpoonPreferredGraspAlignment pycrap.ontologies.crax.CerealPreferredGraspAlignment pycrap.ontologies.crax.World pycrap.ontologies.crax.Floor pycrap.ontologies.crax.Milk pycrap.ontologies.crax.Robot pycrap.ontologies.crax.Cereal pycrap.ontologies.crax.Kitchen pycrap.ontologies.crax.Food pycrap.ontologies.crax.Fruit pycrap.ontologies.crax.Apple pycrap.ontologies.crax.Environment pycrap.ontologies.crax.Apartment pycrap.ontologies.crax.Cup pycrap.ontologies.crax.Spoon pycrap.ontologies.crax.Bowl pycrap.ontologies.crax.PreferredGraspAlignment pycrap.ontologies.crax.XAxis pycrap.ontologies.crax.YAxis pycrap.ontologies.crax.NoAlignment pycrap.ontologies.crax.Truthy pycrap.ontologies.crax.Falsy pycrap.ontologies.crax.Cabinet pycrap.ontologies.crax.Washer pycrap.ontologies.crax.Drawer pycrap.ontologies.crax.Refrigerator pycrap.ontologies.crax.Sink pycrap.ontologies.crax.Door pycrap.ontologies.crax.Cutting pycrap.ontologies.crax.Pouring pycrap.ontologies.crax.Handle pycrap.ontologies.crax.Link pycrap.ontologies.crax.PhysicalObject pycrap.ontologies.crax.PouringTool pycrap.ontologies.crax.CuttingTool pycrap.ontologies.crax.MixingTool pycrap.ontologies.crax.Agent pycrap.ontologies.crax.Human pycrap.ontologies.crax.Room pycrap.ontologies.crax.Location pycrap.ontologies.crax.Container pycrap.ontologies.crax.Joint pycrap.ontologies.crax.ContinuousJoint pycrap.ontologies.crax.HingeJoint pycrap.ontologies.crax.FixedJoint pycrap.ontologies.crax.MovableJoint pycrap.ontologies.crax.FloatingJoint pycrap.ontologies.crax.PlanarJoint pycrap.ontologies.crax.PrismaticJoint pycrap.ontologies.crax.RevoluteJoint pycrap.ontologies.crax.DesignedFurniture pycrap.ontologies.crax.Surface pycrap.ontologies.crax.PhysicalTask pycrap.ontologies.crax.Action pycrap.ontologies.crax.Event pycrap.ontologies.crax.Entity pycrap.ontologies.crax.Task pycrap.ontologies.crax.RootLink pycrap.ontologies.crax.Supporter pycrap.ontologies.crax.SupportedObject pycrap.ontologies.crax.Base pycrap.ontologies.crax.BaseProperty pycrap.ontologies.crax.BaseDatatype pycrap.ontologies.crax.Base pycrap.ontologies.crax.BaseProperty pycrap.ontologies.crax.BaseDatatype pycrap.ontologies.crax.World pycrap.ontologies.crax.Floor pycrap.ontologies.crax.Milk pycrap.ontologies.crax.Robot pycrap.ontologies.crax.Cereal pycrap.ontologies.crax.Kitchen pycrap.ontologies.crax.Food pycrap.ontologies.crax.Fruit pycrap.ontologies.crax.Apple pycrap.ontologies.crax.Environment pycrap.ontologies.crax.Apartment pycrap.ontologies.crax.Cup pycrap.ontologies.crax.Spoon pycrap.ontologies.crax.Bowl pycrap.ontologies.crax.PreferredGraspAlignment pycrap.ontologies.crax.XAxis pycrap.ontologies.crax.YAxis pycrap.ontologies.crax.NoAlignment pycrap.ontologies.crax.Truthy pycrap.ontologies.crax.Falsy pycrap.ontologies.crax.Cabinet pycrap.ontologies.crax.Washer pycrap.ontologies.crax.Drawer pycrap.ontologies.crax.Refrigerator pycrap.ontologies.crax.Sink pycrap.ontologies.crax.Door pycrap.ontologies.crax.Cutting pycrap.ontologies.crax.Pouring pycrap.ontologies.crax.Handle pycrap.ontologies.crax.Link pycrap.ontologies.crax.PhysicalObject pycrap.ontologies.crax.PouringTool pycrap.ontologies.crax.CuttingTool pycrap.ontologies.crax.MixingTool pycrap.ontologies.crax.Agent pycrap.ontologies.crax.Human pycrap.ontologies.crax.Room pycrap.ontologies.crax.Location pycrap.ontologies.crax.Container pycrap.ontologies.crax.Joint pycrap.ontologies.crax.ContinuousJoint pycrap.ontologies.crax.HingeJoint pycrap.ontologies.crax.FixedJoint pycrap.ontologies.crax.MovableJoint pycrap.ontologies.crax.FloatingJoint pycrap.ontologies.crax.PlanarJoint pycrap.ontologies.crax.PrismaticJoint pycrap.ontologies.crax.RevoluteJoint pycrap.ontologies.crax.DesignedFurniture pycrap.ontologies.crax.Surface pycrap.ontologies.crax.PhysicalTask pycrap.ontologies.crax.Action pycrap.ontologies.crax.Event pycrap.ontologies.crax.Entity pycrap.ontologies.crax.Task pycrap.ontologies.crax.RootLink pycrap.ontologies.crax.Supporter pycrap.ontologies.crax.SupportedObject pycrap.ontologies.crax.BowlPreferredGraspAlignment pycrap.ontologies.crax.DefaultPreferredGraspAlignment pycrap.ontologies.crax.SpoonPreferredGraspAlignment pycrap.ontologies.crax.CerealPreferredGraspAlignment pycrap.ontologies.crax.is_part_of pycrap.ontologies.crax.has_part pycrap.ontologies.crax.has_parent_link pycrap.ontologies.crax.has_child_link pycrap.ontologies.crax.contains pycrap.ontologies.crax.contains_object pycrap.ontologies.crax.is_contained_in pycrap.ontologies.crax.has_preferred_alignment pycrap.ontologies.crax.has_preferred_axis pycrap.ontologies.crax.has_vertical_alignment pycrap.ontologies.crax.has_rotated_gripper pycrap.ontologies.crax.has_rim_grasp pycrap.ontologies.crax.is_physically_contained_in pycrap.ontologies.crax.supports pycrap.ontologies.crax.is_supported_by Package Contents ---------------- .. py:class:: World Bases: :py:obj:`Base` The world could be the belief state of an agent about the world. .. py:class:: Floor Bases: :py:obj:`Base` The floor of the world. .. py:class:: Milk Bases: :py:obj:`Base` A milk carton. .. py:class:: Robot Bases: :py:obj:`Base` The robot. .. py:class:: Cereal Bases: :py:obj:`Base` A cereal box. .. py:class:: Kitchen Bases: :py:obj:`Base` A kitchen. .. py:class:: Food Bases: :py:obj:`Base` .. py:class:: Fruit Bases: :py:obj:`Food` .. py:class:: Apple Bases: :py:obj:`Fruit` .. py:class:: Environment Bases: :py:obj:`Base` .. py:class:: Apartment Bases: :py:obj:`Environment` .. py:class:: Cup Bases: :py:obj:`Base` .. py:class:: Spoon Bases: :py:obj:`Base` .. py:class:: Bowl Bases: :py:obj:`Base` .. py:class:: PreferredGraspAlignment Bases: :py:obj:`Base` .. py:class:: XAxis Bases: :py:obj:`Base` .. py:attribute:: value :value: (1, 0, 0) .. py:class:: YAxis Bases: :py:obj:`Base` .. py:attribute:: value :value: (0, 1, 0) .. py:class:: NoAlignment Bases: :py:obj:`Base` .. py:attribute:: value :value: (0, 0, 0) .. py:class:: Truthy Bases: :py:obj:`Base` .. py:attribute:: value :value: True .. py:class:: Falsy Bases: :py:obj:`Base` .. py:attribute:: value :value: False .. py:class:: Cabinet Bases: :py:obj:`Base` .. py:class:: Washer Bases: :py:obj:`Base` .. py:class:: Drawer Bases: :py:obj:`Base` .. py:class:: Refrigerator Bases: :py:obj:`Base` .. py:class:: Sink Bases: :py:obj:`Base` .. py:class:: Door Bases: :py:obj:`Base` .. py:class:: Cutting Bases: :py:obj:`Base` .. py:class:: Pouring Bases: :py:obj:`Base` .. py:class:: Handle Bases: :py:obj:`Base` .. py:class:: Link Bases: :py:obj:`Base` .. py:class:: PhysicalObject Bases: :py:obj:`Base` .. py:class:: PouringTool Bases: :py:obj:`PhysicalObject` The Tool that is used for pouring, can be cup, bottle, etc. .. py:class:: CuttingTool Bases: :py:obj:`PhysicalObject` The tool used for cutting — such as a knife, bread-knife, or similar — depends on the specific task and object being processed. .. py:class:: MixingTool Bases: :py:obj:`PhysicalObject` The tool used for mixing — such as a Spoon, Whisk, or similar — depends on the specific task and object being processed. .. py:class:: Agent Bases: :py:obj:`Base` .. py:class:: Human Bases: :py:obj:`Base` .. py:class:: Room Bases: :py:obj:`Base` .. py:class:: Location Bases: :py:obj:`Base` .. py:class:: Container Bases: :py:obj:`Base` .. py:class:: Joint Bases: :py:obj:`Base` .. py:class:: ContinuousJoint Bases: :py:obj:`Base` A continuous hinge joint that rotates around an axis and has no upper and lower limits. .. py:class:: HingeJoint Bases: :py:obj:`Base` A joint that rotates along an axis. .. py:class:: FixedJoint Bases: :py:obj:`Base` A joint that cannot move, designed to fixiate links. .. py:class:: MovableJoint Bases: :py:obj:`Base` A joint where the two connected links can move relative to each other in some dimension. .. py:class:: FloatingJoint Bases: :py:obj:`Base` A joint that allows motion for all 6 degrees of freedom. .. py:class:: PlanarJoint Bases: :py:obj:`Base` A joint that allows motion in a plane perpendicular to an axis. .. py:class:: PrismaticJoint Bases: :py:obj:`Base` A sliding joint that slides along an axis, and has a limited range specified by the upper and lower limits. .. py:class:: RevoluteJoint Bases: :py:obj:`Base` A hinge joint that rotates along an axis and has a limited range specified by the upper and lower limits. .. py:class:: DesignedFurniture Bases: :py:obj:`Base` An object used to make a room or building suitable for living or working. .. py:class:: Surface Bases: :py:obj:`Base` The outside part or uppermost layer of something. .. py:class:: PhysicalTask Bases: :py:obj:`Base` A task in which a PhysicalAgent affects some physical object. .. py:class:: Action Bases: :py:obj:`Base` An Event with at least one Agent that isParticipantIn it, and that executes a Task that typically isDefinedIn a Plan, Workflow, Project, etc. .. py:class:: Event Bases: :py:obj:`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. (1) 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. (2) 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. (3) 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. .. py:class:: Entity Bases: :py:obj:`Base` Anything: real, possible, or imaginary, which some modeller wants to talk about for some purpose. .. py:class:: Task Bases: :py:obj:`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. .. py:class:: RootLink Bases: :py:obj:`Base` .. py:class:: Supporter Bases: :py:obj:`Base` A physical object that supports another object. .. py:class:: SupportedObject Bases: :py:obj:`Base` A physical object that is supported by another object. .. py:data:: ontology_file .. py:data:: ontology .. py:data:: CRAX_ONTOLOGY_NAME :value: 'PyCRAP' .. py:class:: Base Bases: :py:obj:`owlready2.Thing` .. py:attribute:: namespace .. py:class:: BaseProperty Bases: :py:obj:`owlready2.ObjectProperty` .. py:attribute:: namespace .. py:class:: BaseDatatype Bases: :py:obj:`owlready2.DatatypeProperty` .. py:attribute:: namespace .. py:class:: is_part_of Bases: :py:obj:`BaseProperty` A relation between any entities, e.g. 'brain is a part of the human body'. See dul:hasPart for additional documentation. .. py:class:: has_part Bases: :py:obj:`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. .. py:class:: has_parent_link Bases: :py:obj:`BaseProperty` Relates a joint to the link it connects which is closer to the root of the kinematic chain. .. py:class:: has_child_link Bases: :py:obj:`BaseProperty` Relates a joint to the link it connects which is closer to the end of the kinematic chain. .. py:class:: contains Bases: :py:obj:`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. .. py:class:: contains_object Bases: :py:obj:`BaseProperty` A spatial relation holding between a container, and objects it contains. .. py:class:: is_contained_in Bases: :py:obj:`BaseProperty` The inverse of the contains relation. See the contains relation for details. .. py:class:: has_preferred_alignment Bases: :py:obj:`BaseProperty` A relation between an object and an alignment that is preferred for that object. .. py:class:: has_preferred_axis Bases: :py:obj:`BaseProperty` A relation between an object and an axis identifier. .. py:class:: has_vertical_alignment Bases: :py:obj:`BaseProperty` A relation between an object and boolean value indicating if the object should be grasped with a vertical alignment. .. py:class:: has_rotated_gripper Bases: :py:obj:`BaseProperty` A relation between an object and boolean value indicating if the gripper should be rotated by 90°. .. py:class:: has_rim_grasp Bases: :py:obj:`BaseProperty` A relation between an object and a boolean value indicating if the object should be grasped by the rim. .. py:class:: is_physically_contained_in Bases: :py:obj:`BaseProperty` A spatial relation holding between an object (the container), and objects it contains. .. py:class:: supports Bases: :py:obj:`BaseProperty` A relation between an object (the supporter) and another object (the supportee) where the supporter cancels the effect of gravity on the supportee. .. py:class:: is_supported_by Bases: :py:obj:`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. .. py:data:: ontology_file .. py:data:: ontology .. py:data:: CRAX_ONTOLOGY_NAME :value: 'PyCRAP' .. py:class:: Base Bases: :py:obj:`owlready2.Thing` .. py:attribute:: namespace .. py:class:: BaseProperty Bases: :py:obj:`owlready2.ObjectProperty` .. py:attribute:: namespace .. py:class:: BaseDatatype Bases: :py:obj:`owlready2.DatatypeProperty` .. py:attribute:: namespace .. py:class:: BowlPreferredGraspAlignment Bases: :py:obj:`pycrap.ontologies.crax.classes.PreferredGraspAlignment` .. py:class:: DefaultPreferredGraspAlignment Bases: :py:obj:`pycrap.ontologies.crax.classes.PreferredGraspAlignment` .. py:class:: SpoonPreferredGraspAlignment Bases: :py:obj:`pycrap.ontologies.crax.classes.PreferredGraspAlignment` .. py:class:: CerealPreferredGraspAlignment Bases: :py:obj:`pycrap.ontologies.crax.classes.PreferredGraspAlignment` .. py:class:: World Bases: :py:obj:`Base` The world could be the belief state of an agent about the world. .. py:class:: Floor Bases: :py:obj:`Base` The floor of the world. .. py:class:: Milk Bases: :py:obj:`Base` A milk carton. .. py:class:: Robot Bases: :py:obj:`Base` The robot. .. py:class:: Cereal Bases: :py:obj:`Base` A cereal box. .. py:class:: Kitchen Bases: :py:obj:`Base` A kitchen. .. py:class:: Food Bases: :py:obj:`Base` .. py:class:: Fruit Bases: :py:obj:`Food` .. py:class:: Apple Bases: :py:obj:`Fruit` .. py:class:: Environment Bases: :py:obj:`Base` .. py:class:: Apartment Bases: :py:obj:`Environment` .. py:class:: Cup Bases: :py:obj:`Base` .. py:class:: Spoon Bases: :py:obj:`Base` .. py:class:: Bowl Bases: :py:obj:`Base` .. py:class:: PreferredGraspAlignment Bases: :py:obj:`Base` .. py:class:: XAxis Bases: :py:obj:`Base` .. py:attribute:: value :value: (1, 0, 0) .. py:class:: YAxis Bases: :py:obj:`Base` .. py:attribute:: value :value: (0, 1, 0) .. py:class:: NoAlignment Bases: :py:obj:`Base` .. py:attribute:: value :value: (0, 0, 0) .. py:class:: Truthy Bases: :py:obj:`Base` .. py:attribute:: value :value: True .. py:class:: Falsy Bases: :py:obj:`Base` .. py:attribute:: value :value: False .. py:class:: Cabinet Bases: :py:obj:`Base` .. py:class:: Washer Bases: :py:obj:`Base` .. py:class:: Drawer Bases: :py:obj:`Base` .. py:class:: Refrigerator Bases: :py:obj:`Base` .. py:class:: Sink Bases: :py:obj:`Base` .. py:class:: Door Bases: :py:obj:`Base` .. py:class:: Cutting Bases: :py:obj:`Base` .. py:class:: Pouring Bases: :py:obj:`Base` .. py:class:: Handle Bases: :py:obj:`Base` .. py:class:: Link Bases: :py:obj:`Base` .. py:class:: PhysicalObject Bases: :py:obj:`Base` .. py:class:: PouringTool Bases: :py:obj:`PhysicalObject` The Tool that is used for pouring, can be cup, bottle, etc. .. py:class:: CuttingTool Bases: :py:obj:`PhysicalObject` The tool used for cutting — such as a knife, bread-knife, or similar — depends on the specific task and object being processed. .. py:class:: MixingTool Bases: :py:obj:`PhysicalObject` The tool used for mixing — such as a Spoon, Whisk, or similar — depends on the specific task and object being processed. .. py:class:: Agent Bases: :py:obj:`Base` .. py:class:: Human Bases: :py:obj:`Base` .. py:class:: Room Bases: :py:obj:`Base` .. py:class:: Location Bases: :py:obj:`Base` .. py:class:: Container Bases: :py:obj:`Base` .. py:class:: Joint Bases: :py:obj:`Base` .. py:class:: ContinuousJoint Bases: :py:obj:`Base` A continuous hinge joint that rotates around an axis and has no upper and lower limits. .. py:class:: HingeJoint Bases: :py:obj:`Base` A joint that rotates along an axis. .. py:class:: FixedJoint Bases: :py:obj:`Base` A joint that cannot move, designed to fixiate links. .. py:class:: MovableJoint Bases: :py:obj:`Base` A joint where the two connected links can move relative to each other in some dimension. .. py:class:: FloatingJoint Bases: :py:obj:`Base` A joint that allows motion for all 6 degrees of freedom. .. py:class:: PlanarJoint Bases: :py:obj:`Base` A joint that allows motion in a plane perpendicular to an axis. .. py:class:: PrismaticJoint Bases: :py:obj:`Base` A sliding joint that slides along an axis, and has a limited range specified by the upper and lower limits. .. py:class:: RevoluteJoint Bases: :py:obj:`Base` A hinge joint that rotates along an axis and has a limited range specified by the upper and lower limits. .. py:class:: DesignedFurniture Bases: :py:obj:`Base` An object used to make a room or building suitable for living or working. .. py:class:: Surface Bases: :py:obj:`Base` The outside part or uppermost layer of something. .. py:class:: PhysicalTask Bases: :py:obj:`Base` A task in which a PhysicalAgent affects some physical object. .. py:class:: Action Bases: :py:obj:`Base` An Event with at least one Agent that isParticipantIn it, and that executes a Task that typically isDefinedIn a Plan, Workflow, Project, etc. .. py:class:: Event Bases: :py:obj:`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. (1) 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. (2) 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. (3) 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. .. py:class:: Entity Bases: :py:obj:`Base` Anything: real, possible, or imaginary, which some modeller wants to talk about for some purpose. .. py:class:: Task Bases: :py:obj:`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. .. py:class:: RootLink Bases: :py:obj:`Base` .. py:class:: Supporter Bases: :py:obj:`Base` A physical object that supports another object. .. py:class:: SupportedObject Bases: :py:obj:`Base` A physical object that is supported by another object. .. py:data:: ontology_file .. py:data:: ontology .. py:data:: CRAX_ONTOLOGY_NAME :value: 'PyCRAP' .. py:class:: Base Bases: :py:obj:`owlready2.Thing` .. py:attribute:: namespace .. py:class:: BaseProperty Bases: :py:obj:`owlready2.ObjectProperty` .. py:attribute:: namespace .. py:class:: BaseDatatype Bases: :py:obj:`owlready2.DatatypeProperty` .. py:attribute:: namespace .. py:data:: ontology_file .. py:data:: ontology .. py:data:: CRAX_ONTOLOGY_NAME :value: 'PyCRAP' .. py:class:: Base Bases: :py:obj:`owlready2.Thing` .. py:attribute:: namespace .. py:class:: BaseProperty Bases: :py:obj:`owlready2.ObjectProperty` .. py:attribute:: namespace .. py:class:: BaseDatatype Bases: :py:obj:`owlready2.DatatypeProperty` .. py:attribute:: namespace .. py:class:: World Bases: :py:obj:`Base` The world could be the belief state of an agent about the world. .. py:class:: Floor Bases: :py:obj:`Base` The floor of the world. .. py:class:: Milk Bases: :py:obj:`Base` A milk carton. .. py:class:: Robot Bases: :py:obj:`Base` The robot. .. py:class:: Cereal Bases: :py:obj:`Base` A cereal box. .. py:class:: Kitchen Bases: :py:obj:`Base` A kitchen. .. py:class:: Food Bases: :py:obj:`Base` .. py:class:: Fruit Bases: :py:obj:`Food` .. py:class:: Apple Bases: :py:obj:`Fruit` .. py:class:: Environment Bases: :py:obj:`Base` .. py:class:: Apartment Bases: :py:obj:`Environment` .. py:class:: Cup Bases: :py:obj:`Base` .. py:class:: Spoon Bases: :py:obj:`Base` .. py:class:: Bowl Bases: :py:obj:`Base` .. py:class:: PreferredGraspAlignment Bases: :py:obj:`Base` .. py:class:: XAxis Bases: :py:obj:`Base` .. py:attribute:: value :value: (1, 0, 0) .. py:class:: YAxis Bases: :py:obj:`Base` .. py:attribute:: value :value: (0, 1, 0) .. py:class:: NoAlignment Bases: :py:obj:`Base` .. py:attribute:: value :value: (0, 0, 0) .. py:class:: Truthy Bases: :py:obj:`Base` .. py:attribute:: value :value: True .. py:class:: Falsy Bases: :py:obj:`Base` .. py:attribute:: value :value: False .. py:class:: Cabinet Bases: :py:obj:`Base` .. py:class:: Washer Bases: :py:obj:`Base` .. py:class:: Drawer Bases: :py:obj:`Base` .. py:class:: Refrigerator Bases: :py:obj:`Base` .. py:class:: Sink Bases: :py:obj:`Base` .. py:class:: Door Bases: :py:obj:`Base` .. py:class:: Cutting Bases: :py:obj:`Base` .. py:class:: Pouring Bases: :py:obj:`Base` .. py:class:: Handle Bases: :py:obj:`Base` .. py:class:: Link Bases: :py:obj:`Base` .. py:class:: PhysicalObject Bases: :py:obj:`Base` .. py:class:: PouringTool Bases: :py:obj:`PhysicalObject` The Tool that is used for pouring, can be cup, bottle, etc. .. py:class:: CuttingTool Bases: :py:obj:`PhysicalObject` The tool used for cutting — such as a knife, bread-knife, or similar — depends on the specific task and object being processed. .. py:class:: MixingTool Bases: :py:obj:`PhysicalObject` The tool used for mixing — such as a Spoon, Whisk, or similar — depends on the specific task and object being processed. .. py:class:: Agent Bases: :py:obj:`Base` .. py:class:: Human Bases: :py:obj:`Base` .. py:class:: Room Bases: :py:obj:`Base` .. py:class:: Location Bases: :py:obj:`Base` .. py:class:: Container Bases: :py:obj:`Base` .. py:class:: Joint Bases: :py:obj:`Base` .. py:class:: ContinuousJoint Bases: :py:obj:`Base` A continuous hinge joint that rotates around an axis and has no upper and lower limits. .. py:class:: HingeJoint Bases: :py:obj:`Base` A joint that rotates along an axis. .. py:class:: FixedJoint Bases: :py:obj:`Base` A joint that cannot move, designed to fixiate links. .. py:class:: MovableJoint Bases: :py:obj:`Base` A joint where the two connected links can move relative to each other in some dimension. .. py:class:: FloatingJoint Bases: :py:obj:`Base` A joint that allows motion for all 6 degrees of freedom. .. py:class:: PlanarJoint Bases: :py:obj:`Base` A joint that allows motion in a plane perpendicular to an axis. .. py:class:: PrismaticJoint Bases: :py:obj:`Base` A sliding joint that slides along an axis, and has a limited range specified by the upper and lower limits. .. py:class:: RevoluteJoint Bases: :py:obj:`Base` A hinge joint that rotates along an axis and has a limited range specified by the upper and lower limits. .. py:class:: DesignedFurniture Bases: :py:obj:`Base` An object used to make a room or building suitable for living or working. .. py:class:: Surface Bases: :py:obj:`Base` The outside part or uppermost layer of something. .. py:class:: PhysicalTask Bases: :py:obj:`Base` A task in which a PhysicalAgent affects some physical object. .. py:class:: Action Bases: :py:obj:`Base` An Event with at least one Agent that isParticipantIn it, and that executes a Task that typically isDefinedIn a Plan, Workflow, Project, etc. .. py:class:: Event Bases: :py:obj:`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. (1) 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. (2) 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. (3) 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. .. py:class:: Entity Bases: :py:obj:`Base` Anything: real, possible, or imaginary, which some modeller wants to talk about for some purpose. .. py:class:: Task Bases: :py:obj:`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. .. py:class:: RootLink Bases: :py:obj:`Base` .. py:class:: Supporter Bases: :py:obj:`Base` A physical object that supports another object. .. py:class:: SupportedObject Bases: :py:obj:`Base` A physical object that is supported by another object. .. py:class:: BowlPreferredGraspAlignment Bases: :py:obj:`pycrap.ontologies.crax.classes.PreferredGraspAlignment` .. py:class:: DefaultPreferredGraspAlignment Bases: :py:obj:`pycrap.ontologies.crax.classes.PreferredGraspAlignment` .. py:class:: SpoonPreferredGraspAlignment Bases: :py:obj:`pycrap.ontologies.crax.classes.PreferredGraspAlignment` .. py:class:: CerealPreferredGraspAlignment Bases: :py:obj:`pycrap.ontologies.crax.classes.PreferredGraspAlignment` .. py:class:: is_part_of Bases: :py:obj:`BaseProperty` A relation between any entities, e.g. 'brain is a part of the human body'. See dul:hasPart for additional documentation. .. py:class:: has_part Bases: :py:obj:`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. .. py:class:: has_parent_link Bases: :py:obj:`BaseProperty` Relates a joint to the link it connects which is closer to the root of the kinematic chain. .. py:class:: has_child_link Bases: :py:obj:`BaseProperty` Relates a joint to the link it connects which is closer to the end of the kinematic chain. .. py:class:: contains Bases: :py:obj:`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. .. py:class:: contains_object Bases: :py:obj:`BaseProperty` A spatial relation holding between a container, and objects it contains. .. py:class:: is_contained_in Bases: :py:obj:`BaseProperty` The inverse of the contains relation. See the contains relation for details. .. py:class:: has_preferred_alignment Bases: :py:obj:`BaseProperty` A relation between an object and an alignment that is preferred for that object. .. py:class:: has_preferred_axis Bases: :py:obj:`BaseProperty` A relation between an object and an axis identifier. .. py:class:: has_vertical_alignment Bases: :py:obj:`BaseProperty` A relation between an object and boolean value indicating if the object should be grasped with a vertical alignment. .. py:class:: has_rotated_gripper Bases: :py:obj:`BaseProperty` A relation between an object and boolean value indicating if the gripper should be rotated by 90°. .. py:class:: has_rim_grasp Bases: :py:obj:`BaseProperty` A relation between an object and a boolean value indicating if the object should be grasped by the rim. .. py:class:: is_physically_contained_in Bases: :py:obj:`BaseProperty` A spatial relation holding between an object (the container), and objects it contains. .. py:class:: supports Bases: :py:obj:`BaseProperty` A relation between an object (the supporter) and another object (the supportee) where the supporter cancels the effect of gravity on the supportee. .. py:class:: is_supported_by Bases: :py:obj:`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.