[seek-kr-sms] OBOE discussion: current version

[Ferdinando Villa]

> Also, we need to be very careful about talking about data 
> structure when we talk about oboe.  Not all day is tabular -- 
> and so it is a mistake to design oboe to only work with data 
> formatted this way.

This stuff should be out of OBOE, intended as the Observation Ontology
alone. In what I thought was our consensus after Texas, each annotation has
one and one only "starting point" ObservationRecord [using this new term
provisionally instead of oboe:Observation to avoid confusion] and 0-n
ObservationRecords to provide context for it [you could argue for 2-n,
because observing means at the very least being somewhere at some time, and
no, Euler's number isn't the result of an observation]. That's the statement
of how observations (events) produce datasets. It still includes details
such as characteristic vs. entity that I remember as having been eliminated,
and I personally think will go back to be semantic singularities if we get
to define an observation space or value space.

The way the context defines the number of data points and the arrangement of
the information in the dataset has  nothing to do with the semantics of the
observation, but it pertains to how it is represented (table, parseable text
such as number with units, picture, GIS map, DB query, algorithm/model
producing the data when run). Hence my call for a separate Representation
ontology laying out supported representations, storage types,
precision/uncertainty metrics, and how the contextual mapping is achieved.
(Also note that the Atomic/Compound observation that Sergey talks about is a
leftover in the ontology I gave to Josh - never meant for public view at
that stage - not anything I consider useful or correct.)

Maybe we can get a placet/non placet on these concepts and move on?

ferdinando