pycrap.ontologies.crax.classes ============================== .. py:module:: pycrap.ontologies.crax.classes Classes ------- .. autoapisummary:: pycrap.ontologies.crax.classes.World pycrap.ontologies.crax.classes.Floor pycrap.ontologies.crax.classes.Milk pycrap.ontologies.crax.classes.Robot pycrap.ontologies.crax.classes.Cereal pycrap.ontologies.crax.classes.Kitchen pycrap.ontologies.crax.classes.Food pycrap.ontologies.crax.classes.Fruit pycrap.ontologies.crax.classes.Apple pycrap.ontologies.crax.classes.Environment pycrap.ontologies.crax.classes.Apartment pycrap.ontologies.crax.classes.Cup pycrap.ontologies.crax.classes.Spoon pycrap.ontologies.crax.classes.Bowl pycrap.ontologies.crax.classes.PreferredGraspAlignment pycrap.ontologies.crax.classes.XAxis pycrap.ontologies.crax.classes.YAxis pycrap.ontologies.crax.classes.NoAlignment pycrap.ontologies.crax.classes.Truthy pycrap.ontologies.crax.classes.Falsy pycrap.ontologies.crax.classes.Cabinet pycrap.ontologies.crax.classes.Washer pycrap.ontologies.crax.classes.Drawer pycrap.ontologies.crax.classes.Refrigerator pycrap.ontologies.crax.classes.Sink pycrap.ontologies.crax.classes.Door pycrap.ontologies.crax.classes.Cutting pycrap.ontologies.crax.classes.Pouring pycrap.ontologies.crax.classes.Handle pycrap.ontologies.crax.classes.Link pycrap.ontologies.crax.classes.PhysicalObject pycrap.ontologies.crax.classes.PouringTool pycrap.ontologies.crax.classes.CuttingTool pycrap.ontologies.crax.classes.MixingTool pycrap.ontologies.crax.classes.Agent pycrap.ontologies.crax.classes.Human pycrap.ontologies.crax.classes.Room pycrap.ontologies.crax.classes.Location pycrap.ontologies.crax.classes.Container pycrap.ontologies.crax.classes.Joint pycrap.ontologies.crax.classes.ContinuousJoint pycrap.ontologies.crax.classes.HingeJoint pycrap.ontologies.crax.classes.FixedJoint pycrap.ontologies.crax.classes.MovableJoint pycrap.ontologies.crax.classes.FloatingJoint pycrap.ontologies.crax.classes.PlanarJoint pycrap.ontologies.crax.classes.PrismaticJoint pycrap.ontologies.crax.classes.RevoluteJoint pycrap.ontologies.crax.classes.DesignedFurniture pycrap.ontologies.crax.classes.Surface pycrap.ontologies.crax.classes.PhysicalTask pycrap.ontologies.crax.classes.Action pycrap.ontologies.crax.classes.Event pycrap.ontologies.crax.classes.Entity pycrap.ontologies.crax.classes.Task pycrap.ontologies.crax.classes.RootLink pycrap.ontologies.crax.classes.Supporter pycrap.ontologies.crax.classes.SupportedObject Module 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.