websteps: changes to the oddity model

[bassosimone]

This issue is about changing how the oddity model integrates with websteps. There are actually three set of changes here, and they are described below. We can close this issue once we have implemented these changes.

• terminology changes
• data model issues
• complexity issues

Let me summarize what each of these set of changes is about below.

Terminology changes It seems more natural to think in terms of expected / unexpected than to think in terms of oddities. What is currently named evidence could be hard evidence. What is currently named clue could be soft evidence.

Also, "noise" does not seem like a good term to use here. Better to use "unexplained".

Data model issues It seems more natural to radically separate observations from interpretations. So, if the oddity idea survives this round of feedback, it should in any case be in another data structure that is separated from the observation structure.

Complexity issues Adding the oddity as another level of abstraction on top of the failure complicates understanding the data. So, this begs the question of whether instead the oddity should be some internal value used to simplify computing an overall result.

This specific issue is directly to address feedback that @fortuna and @ohnorobo provided to me when I discussed websteps' design with them.

[bassosimone]

I am not going to do this because websteps and the oddity model are not happening soon. That said, I adopted the expected / unexpected terminology suggested by @fortuna and @ohnorobo, thank you!