-
Notifications
You must be signed in to change notification settings - Fork 0
/
Observation.hs
542 lines (432 loc) · 27 KB
/
Observation.hs
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
{-# 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
-}