Permalink
Cannot retrieve contributors at this time
{-# LANGUAGE MultiParamTypeClasses #-} | |
{- Perception-Action Ontology | |
An algebraic specification of observations and actions resulting from perception. | |
The code is an ontology, specifying the concepts, as well as a simulation, providing an executable model. | |
The goal is to understand the information processing involved, not the physics or psychology of agents. | |
Theoretical challenges addressed: | |
- exploit the parallel between perception leading to observed values and perception leading to actions | |
- clarify status of affordances in ontology | |
- exploit the potential of affordances to unite realist and conceptualist views | |
- work toward a general theory for the locating and timing of observations | |
- deal with resolution and uncertainty in sensor standards | |
- generalize over human and technical observations | |
Practical goals: | |
- treat sensor systems and sensor networks also as (single) sensors | |
- connect the sensor web to the rest of the web | |
- allow users to assess whether sensor services are semantically interoperable | |
- clarify basic terminology in sensor standards ("phenomenon", "feature of interest", sensors as processes ...) | |
- produce observation ontologies defining observation semantics, rather than devices and data structures | |
Building on ideas from: | |
- OGC Standards (Observations and Measurements, SensorML): terminology, sensors as processes | |
- Webster 1999: Measurement, Instrumentation, and Sensors Handbook (CRC) | |
- Probst 2008: Observations, measurements and semantic reference spaces | |
- Frank 2009: Why Is Scale an Effective Descriptor for Data Quality? (chapter in Navratil book) | |
- Frank 2001 ontological tiers (but we make less assumptions, e.g. points need no qualities which can be measured) | |
- Hayes 1985: Ontology for Liquids | |
- DOLCE D18 | |
- Warren 1984 | |
- Turvey 1992 | |
- Stoffregen 2000 | |
Basic terminology: | |
- OGC Observations and Measurements: "An Observation is an action with a result which has a value describing some phenomenon." | |
- OGC Reference Model: "An observation is an act associated with a discrete time instant or period through which | |
a number, term or other symbol is assigned to a phenomenon." | |
- Wikipedia: A "stimulus (plural stimuli) is a detectable change in the internal or external environment". | |
Basic ontological commitments: | |
1. Following DOLCE, four categories of individuals are distinguished: endurants, perdurants, abstracts, and qualities. | |
- Perdurants have endurants participating in them. | |
- Qualities are what agents perceive. | |
- Qualities inhere in individuals of any of the four top level categories (including arbitrary sums!). | |
- Qualities can be physical (inhering in endurants), temporal (inhering in perdurants), or abstract (inhering in abstracts). | |
2. Human and technical sensors are agentive physical objects (agents, for short). | |
3. Agents perceive qualities through stimuli. | |
4. Stimuli are perdurants with participating quality bearers and agents. | |
5. Agents can observe perceived qualities. | |
6. Agents can act on perceived affordances. | |
7. Afforded actions are intentional. | |
8. Perceiving is not afforded, as it is not necessarily intentional. | |
9. Locations are not introduced as entities. Physical endurants locate other physical endurants through image schematic relations. | |
Stimuli can be | |
- physical processes involving a bearing endurant (e.g., heat transmission from an amount of air to a thermometer) | |
- bearers of observed temporal qualities (e.g., an earthquake) | |
They can also be produced by an observer (e.g., a sonar wave to measure distance). | |
Stimuli are detected through | |
- a changing physical quality of a participating endurant, or | |
- a temporal quality of the stimulus or of a perdurant coupled with it. | |
The detection of stimuli results in analog signals, which are called qualia here. | |
- the term is used here for human qualia and (metaphorically) for technical sensors | |
- an agent can have any number of qualia (though we model only one for now) | |
- there are no complex qualia for now, as it makes more sense to combine qualia when expressing values, not when perceiving multiple qualities | |
- hypothesis: a quale corresponds to a dimension in a conceptual space (consistent with DOLCE) | |
- this implies that qualia have an order relation | |
- simplest model is Float (an intensity or magnitude of perception) | |
- use Goguen's piece on qualia (esp. keio04) to refine later | |
- each quale will eventually be the result of a convolution of stimuli over space and time | |
- qualia are not mental objects, but something like mental features (they depend on an agent). | |
Observation values | |
- according to [Fowler 1998, SensorML], they can be boolean, count, measure with a unit, or category (nominal or ordinal) | |
- but O&M allows any type as value, and we clearly need more (images, URLs, ...). | |
- use base types and introduce additional types where needed | |
- all types require an order relation (i.e. need to be instances of Ord) | |
- measurement units are the subject of their own ontology under development, we consider them to inhere in result values | |
Sensor systems and sensor networks: | |
- A sensor system is a collocated aggregate of sensors. | |
- A sensor network is a set of communicating sensors. | |
- Sensor systems and sensor networks can act as sensors observing a (single) complex observable. | |
Examples of | |
- physical qualities: the temperature of an amount of air, the taste of a glass of wine | |
- temporal qualities: the moment of a sunset, the duration of an earthquake | |
- physical affordances: the climbability of a step, the drinkability of water | |
- stimuli: the flow of heat energy, sound waves traveling to a surface and back | |
- sensor systems: a weather station aggregating individual sensor measurements, a doctor observing a patient and describing the patient's mood | |
- sensor networks: ... | |
Formalization: | |
We distinguish DOLCE's four top level categories formally, based on Haskell kinds: | |
1. A quality is specified as a data constructor applied to any entity (e.g., "Temperature muensterAir"). | |
2. A quality type (a.k.a. property) is specified as a data constructor (e.g., "Temperature"). | |
3. Endurants are of types with kind * | |
4. Perdurants are of types with higher kind than *. | |
5. Abstracts are of any kind and have no data constructors. (Not so sure about that yet.) | |
Modeling decisions: | |
All entities are specified only minimally, recording the ontological distinctions deemed necessary for the envisioned reasoning. | |
Individual qualities are understood to exist in mind-independent reality (as "ecological facts"). | |
For example, a room has a temperature independently of any observers, and a step has a climbability independently of any observer. | |
Amounts of stuff are not parameterized in the stuff (e.g., air), because DOLCE does not consider stuff as such to be a particular. | |
Qualia are modelled as magnitudes in a (for simplicity) one-dimensional quality space. | |
Gains: an ontology of observation that... | |
- takes the form of a simulation | |
- grounds the semantics of observations in semantic datums | |
- includes affordances | |
- separates sensors as agents from sensing (i.e., observing) as process | |
- specifies what a "phenomenon" (OGC) is, namely a quality of an endurant or perdurant | |
- specifies what a "feature of interest" (OGC) is, namely a physical endurant or perdurant | |
- distinguishes observations related to endurants from those related to perdurants | |
- distinguishes internal (to the observer) and external bearers of qualities | |
- formalizes sensor fusion by recursion (observing observation results in sensor systems and sensor networks) | |
- is neutral w.r.t. the field vs object distinction (both views are compatible with the ontology) | |
- treats observation results (values or actions) as dependent on agents. | |
To Do: | |
- pay attention to null value for qualia so that the datum functions in observations do not produce nonsense | |
- the semantic datum will have to specify the thematic resolution (a.k.a. discrimination) | |
- spatial and temporal datums will be shown to be just special cases | |
- introduce notion of virtual sensor (as observation data stream), like swiss-experiment | |
- Relaxing the physical law connection between observed and targeted phenomena (use correct terms) | |
- relate to Vanicek model for observables | |
- switch to dolce core? | |
- should affordances be gradual? | |
- specify Stevens (and other) scales of measurement | |
- hypothesis: measurement scales are determined by the admissible operations on qualia (journal 5 jan 10) | |
- model more affordances from the literature, including social ones | |
- model step climbability for a wheel chair user | |
- turn time and position into observations (of an observation, of an agent, of an entity) | |
- these have reference systems like all other observations | |
- reintroduce sensor observations for coordinates or a toponym or a "cloud" of positions or a function of ClockTime | |
- add direction as observation of orientation | |
- define position relationally: support by a surface, containment by a medium, anything else? | |
- define time relationally: preceding or during or following an event | |
- link to medium, substance, surface (from which endurants, qualities, and perdurants derive) | |
- extend with trust and reputation measures | |
- treat sensor dust as a case where the individual sensors do not position themselves | |
- introduce time-varying endurants | |
- model convolutions and uncertainty (showing that the notions of "error" and "true value" are unnecessary) | |
- model scale transitions (see also CC Gibson paper) | |
- model perdurants of change as instances (types) of image schema combinations | |
- define kinds of perdurant couplings | |
- implement datum transformations | |
- note (JO): agents set up an ego-centric reference system by partitioning a (presumed) quality space with their own dimensions | |
- extend by actuators (cute example dealing with uncertainty: Schrödinger's cat!) | |
- close some action-perception-action loops | |
- build sensorimotor loop simulations to define semantics | |
- specify the negotiation of semantics in action-perception cycles (the observed entity is another agent) | |
- specify calibration as the process to establish semantic datums | |
- test with geodetic datum | |
Haskell improvements: | |
- check phantom types for actual subtypes, and haddock and hls for the comments, and astypeof (prelude) | |
- read hlist article by Laemmel | |
- read GADT Simon Peyton Jones | |
Adding code for grounding (COSIT 2009 paper): | |
- instead of places as primitives, can we use regions of objects, amounts of matter, or features? | |
- no: we need empty places; so, only abstract (not derived from entities) regions work | |
Recent changes and issues: | |
- dropped claim that quality constructors applied to entities represent qualia or regions in quality spaces (they do not, as the agent is missing) | |
- dropped commitment that a quality maps endurants or perdurants to an abstract region in a quality space (may be true, but is not needed yet) | |
- perceiving is now the first step in observing all qualities (including affordances) | |
- observations and actions require an intention (coming from outside the system) and operate on the agent holding the necessary qualia | |
- abandoned the explicit act abstraction, as it is strenouous and now not needed without the compositional axiom above | |
- qualia and values require an order relation (by their nature and to reason when converting qualia to values) | |
- replaced the single data types Value and Quale by specialized value and qualia types, in order to constrain operations on them (such as <) | |
- this is possible because we have no free standing Value or Quale operation results (they only occur in agents) | |
- abandoned reading qualities, as they are not needed (sensor fusion in sensor systems can access component sensor values directly) | |
- reintroduced labeled fields, for better readability of axioms | |
- abandoned explicit type classes for DOLCE top level (ABSTRACTS, ENDURANTS, PERDURANTS, QUALITIES) | |
- renamed APOS to AGENTS, for readability | |
- separated an ACTIONS class from the OBSERVATIONS class, to keep the terminology simple | |
(c) Werner Kuhn | |
Improved by contributions from Jens Ortmann, Krzysztof Janowicz, Andrew Frank, and Simon Scheider | |
and comments from Christoph Stasch, Arne Broering, and Ilka Reis | |
Last modified: 16 Jun 2010 (WK) | |
-} | |
module Observation where | |
type Id = Int -- an identifier | |
--------------------------------- | |
-- Physical Endurants | |
class PHYSICAL_ENDURANTS physicalEndurant | |
class PHYSICAL_ENDURANTS amountOfMatter => AMOUNTS_OF_MATTER amountOfMatter | |
class PHYSICAL_ENDURANTS physicalObject => PHYSICAL_OBJECTS physicalObject | |
class PHYSICAL_OBJECTS agent => AGENTS agent -- agentive physical objects | |
-- amounts of air have heat and moisture | |
data AmountOfAir = AmountOfAir {heat:: Float, moisture:: Float} deriving (Eq, Show) | |
muensterAir = AmountOfAir {heat = 20.0, moisture = 70.0} | |
instance PHYSICAL_ENDURANTS AmountOfAir | |
instance AMOUNTS_OF_MATTER AmountOfAir | |
-- steps (of a stair) have an Id and a riser height | |
data Step = Step {sid:: Id, riserHeight:: Float} deriving Show | |
instance Eq Step where Step id1 _ == Step id2 _ = id1 == id2 | |
ground = Step {sid = 0, riserHeight = 0.0} | |
step1 = Step {sid = 1, riserHeight = 0.18} | |
step2 = Step {sid = 2, riserHeight = 0.18} | |
instance PHYSICAL_ENDURANTS Step | |
instance PHYSICAL_OBJECTS Step | |
-- trees have an Id and a crown diameter | |
data Tree = Tree {trid:: Id, crownDiameter:: Float} deriving Show | |
instance Eq Tree where Tree id1 _ == Tree id2 _ = id1 == id2 | |
thePine = Tree {trid = 1, crownDiameter = 10.0} | |
theCypress = Tree {trid = 2, crownDiameter = 2.0} | |
instance PHYSICAL_ENDURANTS Tree | |
instance PHYSICAL_OBJECTS Tree | |
-- bridges have an Id and link two endurants (represented by their ids) | |
data Bridge = Bridge {brid:: Id, oneEnd, otherEnd :: Id} deriving Show | |
instance Eq Bridge where Bridge id1 _ _ == Bridge id2 _ _ = id1 == id2 | |
theBridge = Bridge {brid = 0, oneEnd = rbid leftBank, otherEnd = rbid rightBank} | |
instance PHYSICAL_ENDURANTS Bridge | |
instance PHYSICAL_OBJECTS Bridge | |
data RiverBank = RiverBank {rbid:: Id} deriving Show | |
instance Eq RiverBank where RiverBank id1 == RiverBank id2 = id1 == id2 | |
leftBank = RiverBank {rbid = 1} | |
rightBank = RiverBank {rbid = 2} | |
-- a person has an id, a leg length, an id of an endurant locating it, a current quale, and an output string | |
data Person = Person {pid:: Id, legLength:: Float, loc:: Id, pQuale:: Float, pValue:: String} deriving Show | |
ann = Person {pid = 1, legLength = 0.8, loc = 0, pQuale = 0.0, pValue = ""} | |
instance Eq Person where Person id1 _ _ _ _ == Person id2 _ _ _ _ = id1 == id2 | |
instance PHYSICAL_ENDURANTS Person | |
instance PHYSICAL_OBJECTS Person | |
instance AGENTS Person | |
-- a thermometer has an id, a quale, and a float temperature value | |
data Thermometer = Thermometer {tid:: Id, tQuale:: Float, tValue:: Float} deriving Show | |
fmoThermometer = Thermometer {tid = 1, tQuale = 0.0, tValue = 0.0} | |
instance Eq Thermometer where Thermometer id1 _ _ == Thermometer id2 _ _ = id1 == id2 | |
instance PHYSICAL_ENDURANTS Thermometer | |
instance PHYSICAL_OBJECTS Thermometer | |
instance AGENTS Thermometer | |
-- a hygrometer has an id, a quale, and a float humidity value (percentage) | |
data Hygrometer = Hygrometer {hid:: Id, hQuale:: Float, hValue:: Float} deriving Show | |
fmoHygrometer = Hygrometer {hid = 1, hQuale = 0.0, hValue = 0.0} | |
instance Eq Hygrometer where Hygrometer id1 _ _ == Hygrometer id2 _ _ = id1 == id2 | |
instance PHYSICAL_ENDURANTS Hygrometer | |
instance PHYSICAL_OBJECTS Hygrometer | |
instance AGENTS Hygrometer | |
-- a weather station has an id, a thermometer, a hygrometer, and an output string value | |
-- the thermometer and hygrometer are the holders of the temperature and humidity qualia of the weather station | |
data WeatherStation = WeatherStation {wid:: Id, thermo:: Thermometer, hygro:: Hygrometer, wValue:: String} deriving Show | |
fmoWeatherStation = WeatherStation {wid = 1, thermo = fmoThermometer, hygro = fmoHygrometer, wValue = ""} | |
instance PHYSICAL_ENDURANTS WeatherStation | |
instance PHYSICAL_OBJECTS WeatherStation | |
instance AGENTS WeatherStation | |
---------------------------------------------------------------------- | |
-- Qualities | |
-- the class of all quality types (= properties) is a constructor class | |
-- its constructors can be applied to endurants, perdurants, qualities or abstracts | |
-- this seems to work with entities of different kinds (tested for *->*) | |
class QUALITIES quality entity | |
-- the temperature quality | |
data PHYSICAL_ENDURANTS physicalEndurant => Temperature physicalEndurant = Temperature physicalEndurant deriving Show | |
instance QUALITIES Temperature AmountOfAir | |
-- the humidity quality | |
data AMOUNTS_OF_MATTER amountOfAir => Humidity amountOfAir = Humidity amountOfAir deriving Show | |
instance QUALITIES Humidity AmountOfAir | |
-- the weather quality (change bearer to place!) | |
data AMOUNTS_OF_MATTER amountOfAir => Weather amountOfAir = Weather amountOfAir deriving Show | |
instance QUALITIES Weather AmountOfAir | |
-- the height of steps quality | |
data PHYSICAL_OBJECTS step => Height step = Height step deriving Show | |
instance QUALITIES Height Step | |
---------------------------------------------------------------------- | |
-- Affordances | |
-- the class of all affordance types is a sub-class of QUALITIES | |
-- the reason for introducing this sub-class is to be able to constrain ACTIONS | |
-- the constructors can (for now) only be applied to endurants | |
-- later, this may be generalized to other affording entities | |
class (QUALITIES affordance physicalEndurant, PHYSICAL_ENDURANTS physicalEndurant) => AFFORDANCES affordance physicalEndurant | |
-- the climbability of steps affordance | |
data PHYSICAL_OBJECTS step => Climbability step = Climbability step deriving Show | |
instance QUALITIES Climbability Step | |
instance AFFORDANCES Climbability Step | |
-- the sheltering of trees affordance | |
data PHYSICAL_OBJECTS tree => Shelter tree = Shelter tree deriving Show | |
instance QUALITIES Shelter Tree | |
instance AFFORDANCES Shelter Tree | |
-- the crossability of bridges affordance | |
data PHYSICAL_OBJECTS bridge => Crossability bridge = Crossability bridge deriving Show | |
instance QUALITIES Crossability Bridge | |
instance AFFORDANCES Crossability Bridge | |
----------------------------------------- | |
-- Stimuli enable agents to perceive qualities | |
-- their physical and physiological nature is intentionally left unspecified | |
-- the simplest implementation for qualia is to set them equal to the corresponding parameters in the observed entities | |
class (QUALITIES quality entity, AGENTS agent) => STIMULI quality entity agent where | |
perceive :: quality entity -> agent -> agent | |
instance STIMULI Temperature AmountOfAir Person where | |
perceive (Temperature amountOfAir) person = person {pQuale = heat amountOfAir} | |
ptp = perceive (Temperature muensterAir) ann | |
instance STIMULI Temperature AmountOfAir Thermometer where | |
perceive (Temperature amountOfAir) thermometer = thermometer {tQuale = heat amountOfAir} | |
ptt = perceive (Temperature muensterAir) fmoThermometer | |
instance STIMULI Humidity AmountOfAir Hygrometer where | |
perceive (Humidity amountOfAir) hygrometer = hygrometer {hQuale = moisture amountOfAir} | |
phh = perceive (Humidity muensterAir) fmoHygrometer | |
instance STIMULI Weather AmountOfAir WeatherStation where | |
perceive (Weather amountOfAir) weatherStation = | |
weatherStation {thermo = observe (Temperature amountOfAir) (thermo weatherStation), | |
hygro = observe (Humidity amountOfAir) (hygro weatherStation)} | |
pww = perceive (Weather muensterAir) fmoWeatherStation | |
instance STIMULI Height Step Person where | |
perceive (Height step) person = person {pQuale = riserHeight step} | |
php = perceive (Height step1) ann | |
instance STIMULI Climbability Step Person where | |
perceive (Climbability step) person = person {pQuale = riserHeight step} | |
pcp = perceive (Climbability step1) ann | |
-- height should take current level of person into account | |
-- climbability could be determined more broadly, not just from height | |
-- the numeric equivalence of the qualia for height and climbability is only for simplicity; they are conceptually different | |
instance STIMULI Shelter Tree Person where | |
perceive (Shelter tree) person = person {pQuale = crownDiameter tree} | |
psp = perceive (Shelter thePine) ann | |
psc = perceive (Shelter theCypress) ann | |
instance STIMULI Crossability Bridge Person where | |
perceive (Crossability bridge) person = person {pQuale = 1.0} -- all bridges are crossable by people, thus arbitrary value for quale | |
pcb = perceive (Crossability theBridge) ann | |
{---------------------------------------- to be done after the AO paper | |
-- Semantic Datums | |
-- they map from qualia (for a quality) to values and back | |
-- agents can adopt suitable datum definitions | |
class QUALITIES quality entity => DATUMS quality entity quale value where | |
encode :: quale -> value | |
decode :: value -> quale | |
heat2temp1 :: Float -> Float | |
heat2temp1 f = f | |
temp2heat1 :: Float -> Float | |
temp2heat1 f = f | |
class DATUMS quality entity quale value => INTERVAL_DATUMS quality entity quale value | |
instance DATUMS Temperature AmountOfAir Float Float where | |
encode = heat2temp1 | |
decode = temp2heat1 | |
-----------------------} | |
-- Observations | |
-- to observe a quality is to express the result of perceiving one or more (possibly proxy) qualities by a value (carried by an agent) | |
class STIMULI quality entity agent => OBSERVATIONS quality entity agent where | |
observe :: quality entity -> agent -> agent | |
instance OBSERVATIONS Temperature AmountOfAir Person where | |
observe (Temperature amountOfAir) person = person {pValue = | |
if (pQuale (perceive (Temperature amountOfAir) person)) > 15 then "warm" else "cold"} | |
otp = observe (Temperature muensterAir) ann | |
instance OBSERVATIONS Temperature AmountOfAir Thermometer where | |
observe (Temperature amountOfAir) thermometer = thermometer {tValue = tQuale (perceive (Temperature amountOfAir) thermometer)} | |
ott = observe (Temperature muensterAir) fmoThermometer | |
instance OBSERVATIONS Humidity AmountOfAir Hygrometer where | |
observe (Humidity amountOfAir) hygrometer = hygrometer {hValue = hQuale (perceive (Humidity amountOfAir) hygrometer)} | |
ohh = observe (Humidity muensterAir) fmoHygrometer | |
instance OBSERVATIONS Weather AmountOfAir WeatherStation where | |
observe (Weather amountOfAir) weatherStation = | |
weatherStation {wValue = | |
if ((tValue (observe (Temperature amountOfAir) (thermo weatherStation))) > 18) && | |
((hValue (observe (Humidity amountOfAir) (hygro weatherStation))) < 80) | |
then "fair" else "bad"} | |
oww = observe (Weather muensterAir) fmoWeatherStation | |
instance OBSERVATIONS Height Step Person where | |
observe (Height step) person = | |
person {pValue = if (pQuale (perceive (Height step) person)) / (legLength person) < 0.26 then "low" else "high"} | |
ohp = observe (Height step1) ann | |
----------------------------------------------- | |
-- Actions | |
-- to act on an affordance is to enact the result of perceiving one or more (possibly proxy) affordances | |
class (AFFORDANCES affordance physicalEndurant, STIMULI affordance physicalEndurant agent) => ACTIONS affordance physicalEndurant agent where | |
act :: affordance physicalEndurant -> agent -> agent | |
instance ACTIONS Climbability Step Person where | |
act (Climbability step) person = | |
if (pQuale (perceive (Climbability step) person)) / (legLength person) < 0.88 then person {loc = sid step} else person | |
ac1 = act (Climbability step1) ann | |
ac2 = act (Climbability step2) ac1 | |
instance ACTIONS Shelter Tree Person where | |
act (Shelter tree) person = | |
if (pQuale (perceive (Shelter tree) person)) > 2.5 then person {loc = trid tree} else person | |
asp = act (Shelter thePine) ann | |
asc = act (Shelter theCypress) ann | |
instance ACTIONS Crossability Bridge Person where | |
act (Crossability bridge) person = person {loc = otherEnd bridge} | |
acb = act (Crossability theBridge) ann | |
{- | |
**** use later ******* | |
-- mosquito eggs | |
-- ein Ei gleicht dem anderen | |
data Egg = Egg deriving (Eq, Show) | |
-- a collection of mosquito eggs | |
data Eggs = Empty | Add Egg Eggs deriving (Eq, Show) | |
someEggs = Add Egg (Add Egg Empty) | |
countEggs Empty = 0 | |
countEggs (Add Egg eggs) = countEggs eggs + 1 | |
instance ENDURANTS Egg | |
instance PHYSICAL_ENDURANTS Egg | |
instance PHYSICAL_OBJECTS Egg | |
instance ENDURANTS Eggs | |
-- the count quality: tbd (with collection) | |
data PHYSICAL_ENDURANTS physicalEndurant => Number physicalEndurant = Number physicalEndurant | |
type EggNumber = Number Eggs | |
instance OBSERVERS (Sensor eggNumber) Eggs where | |
observe (Sensor eggNumber agent) eggs = do | |
clockTime <- getClockTime | |
let time = calendarTimeToString (toUTCTime clockTime) | |
let position = getPosition agent clockTime | |
let value = Count (countEggs eggs) | |
return (Observation value position time) | |
-------------------------------- | |
-- features (not yet used) | |
class PHYSICAL_ENDURANTS feature => FEATURE feature | |
-- non-physical endurants | |
class ENDURANTS nonphysicalEndurant => NONPHYSICAL_ENDURANTS nonphysicalEndurant | |
-- non-physical objects | |
class NONPHYSICAL_ENDURANTS nonphysicalObject => NONPHYSICAL_OBJECTS nonphysicalObject | |
-- social objects (not yet used) | |
class NONPHYSICAL_OBJECTS socialObject => SOCIAL_OBJECTS socialObject | |
-- mental objects | |
-- they are specifically dependent on agents (i.e., not just persons) | |
-- should this be stated in the context (and how)? | |
class NONPHYSICAL_OBJECTS mentalObject => MENTAL_OBJECTS mentalObject | |
------------------------------- | |
-- networks of observing agents | |
-- one can ask for all neighbors of a node (tbd) | |
-- connectivity is modeled as adjacency matrix | |
data AGENTS agent => Network agent = Network [[Int]] [agent] | |
instance ENDURANTS (Network agent) | |
instance PHYSICAL_ENDURANTS (Network agent) | |
instance PHYSICAL_OBJECTS (Network agent) where | |
getPosition (Network links agents) = Cloud (map getPosition agents) | |
instance AGENTS (Network agent) | |
**** cuts ******* | |
True, but not really relevant: | |
The parametrization of quality types (e.g., temperature of any physical endurant) is possible because qualities are modeled as constructors. | |
The quality parameter in an observer definition needs to refer to a specific endurant or perdurant type (thermometers are designed for air or water). | |
This is only possible if it is a (polymorphic) constructor function, which has different signatures for different endurants and perdurants. | |
For example, the temperature of air and that of water have two signatures with the same constructor, but different input types. | |
A further advantage of using constructors is that their type constructors (left-hand side) can have the same name. | |
once we introduce reference systems, possibly reuse this: | |
data RefSys = EPSG Int | BodyRef String deriving (Eq, Show) | |
fmo = Coordinates [52.08, 7.41] (EPSG 4326) | |
eyeLevel = Coordinates [1.70] (BodyRef "Height") | |
-- physical qualities inhere in physical endurants | |
class (QUALITIES quality entity, PHYSICAL_ENDURANTS entity) => PHYSICAL_QUALITIES quality entity | |
instance PHYSICAL_QUALITIES Temperature AmountOfAir | |
-- temporal qualities inhere in perdurants | |
class (QUALITIES quality entity, PERDURANTS entity) => TEMPORAL_QUALITIES quality entity | |
-- abstract qualities inhere in abstract entities (for example, in descriptions) | |
class (QUALITIES quality entity, ABSTRACTS entity) => ABSTRACT_QUALITIES quality entity | |
-} |