Update /Observation in light of pending experience including datacommons.org

[danbri]

Data Commons have been using /Observation heavily, and @darobin has also been looking into using it (see https://gist.github.com/darobin/07324754f0db7f090d737b9d2616536c). The /Observation type is in "Pending" status currently which means we are looking for feedback. This issue is to make some updates based on implementor experience.

[smrgeoinfo]

Why does 'marginOfError' have expected type 'DateTime'. The marginOfError should have a numeric value with some specification of the statistic used to estimate the margin of error, thus itself is actually an observation result.

[smrgeoinfo]

Seems like it would be good to align the schema.org observation with the w3c SOSA observation "Observation - Act of carrying out an (Observation) Procedure to estimate or calculate a value of a property of a FeatureOfInterest. Links to a Sensor to describe what made the Observation and how; links to an ObservableProperty to describe what the result is an estimate of, and to a FeatureOfInterest to detail what that property was associated with.'

Looks like observedNode would map to FeatureOfInterest.
measuredProperty maps to ObservableProperty
measuredValue maps to result
Procedure is missing AFAICT in the schema.org proposal, but is important to understand and trust an observation result. For example in the gist referenced above, I would really like to know how and by who those numbers were compiled.

[darobin]

Having seen first-hand the work that the NYT folks need to do to get at such data, I believe that this could prove very useful and is worth shipping early even if it may be imperfect at first.

[dr-shorthair]

A proposed mapping between Schema.org and SOSA was prepared a couple of years ago - see https://github.com/w3c/sdw/blob/gh-pages/ssn/rdf/sosa-sdo-mapping.ttl
I note that a few other new properties are proposed here, so some of the mapping mentioned above would have to be adjusted if this proposal was accepted.

A few details:

1. I suggest moving Observation so that its parent is Action rather than Intangible (The Observation type had not been introduced to Schema.org at that time, so in the mapping we used Action imagining that was a suitable super-type.)

Note that the tension between

• observation={information-object} and
• observation={act-to-generate-information}

was the topic of much discussion in the W3C project that generated the SOSA vocabulary before we came down on the side of it being an Action, partly through analogy with PROV and BFO.

2. What is the relationship between measuredProperty and variableMeasured? They come from different origins (domain: dataset vs observation), but is there a good reason for duplicating the function with two tags?

3. In place of measuredValue (which is not yet in the Schema.org canon) could you call it result - this follows from the idea that an Observation is an action whose outcome is new information.

4. In SOSA (and its predecessors) we recognised that there was potentially more than one date/time associated with an observation. There are many, but the two most widely required are

(1) the time in the world that the result describes (which is usually what an analyst is interested in)
(2) the time that the result became available (more related to data management).

In general these are not the same. At the very least there is likely to be a data-processing and communications lag which will put the result-time later than the phenomenon-time. While this may or may not be important, having both slots explicit makes the structure also useful

• for forecasts (when the result-time is before the phenomenon-time) or
• for historical/archaeological/geological/cosmological observations (when the result-time is a long way later than the phenomenon-time).

I suspect that observationDate is intended to be the phenomenon-time, but this should at least be clear from the documentation.

5. A link to the protocol and sensor/observer is missing. This is important metadata/quality information.

[smrgeoinfo]

schema.org Action does seem like a better parent class for observation: it accounts for

• Agent-- who made the observation
• startTime, endTime-- when the observation was made
• instrument-- the sensor or other instrument used to make the observation
• location-- where was the observation made.
• object-- doesn't seem like too much of a stretch to make this 'feature of interest' (is that the intention of 'observedNode'???)
• result-- this would have to have range 'measuredValue' that would be a quantifier--numeric or categorical, with uncertainty

I agree that measuredProperty and variableMeasured are redundant. Keep variableMeasured since its already there.

Location-- Have to clarify the location of the feature of interest from the location of the observer, e.g. where was the satellite as opposed to what was the satellite imaging, or where the sample was collected in the field from the location of the lab where it was analyzed.

reiterating issues Simon brought up:

• observation time is commonly more complex that a simple calendar date/time interval
• distinguish phenomenon time from observation time (perhaps other time semantics)
• Need to have a link to the protocol/method/procedure for how the observation was made/obtained.

[ramonawalls]

I second the suggestions from @smrgeoinfo and @dr-shorthair. Particularly important is the change to make Observation a child of Action rather than Intangible.

[danbri]

Several people have suggested that we put Schema.org/Observation below /Action. I can see how this makes sense, in that observing is a kind of action. However I am wary of doing so, in that the Schema.org Actions design has its own complications (including an associated protocol) and after some years only a patchy implementation story. I am wary of complicating the picture further by mixing this work in there. Similarly, there is a case that actions are events; and yet we have chosen not to entangle those pieces of the design either, for now at least.

[dr-shorthair]

On the detailed matter that you bring up @danbri, every sosa:Observation (from W3C SSN) has a usedProcedure property which I think carries related information to your protocol. (Note that this is separate from instrument which in this context implements the procedure.) So I don't think there is necessarily such a clash. Now I can imagine that Action as originally conceived had distinct behaviour, but maybe it is not so different.

There is already quite a rich set of sub-classes of Action. I'd be comfortable seeing Observation slot in there.

[github-actions]

This issue is being tagged as Stale due to inactivity.

[dr-shorthair]

Looking at W3C/OGC sosa::Observation I had proposed the following alignment to the Schema.org/CreateAction, on the principle that an Observation is an action that creates information.

(The other 'actions' in SOSA/SSN are sosa:Sampling - which creates a Sample, and sosa:Actuation, which results in a change of state.)

sosa:Observation has a set of standard properties which could be aligned to Schema.org as follows

sosa:Observation rdfs:subClassOf schema:CreateAction . 

sosa:usedSensor rdfs:subPropertyOf schema:instrument .
sosa:usedProcedure owl:equivalentProperty schema:measurementTechnique .
sosa:hasFeatureOfInterest rdfs:subPropertyOf schema:object .
sosa:observedProperty owl:equivalentProperty schema:measuredProperty .
sosa:result rdfs:subPropertyOf schema:result .
sosa:resultTime rdfs:subPropertyOf schema:endTime .
sosa:phenomenonTime rdfs:subPropertyOf schema:temporalCoverage . 

Schema.org/Observation type is not tied to the Action hierarchy. @danbri provides some explanation above #2564 (comment) But I would argue that unless the Action hierarchy is removed, then it makes no sense for Observation not to sit there.

(Modified 2022-08-31 - added sosa:usedProcedure and amended sosa:observedProperty mappings.)

[dr-shorthair]

@danbri wrote

the Schema.org Actions design has its own complications (including an associated protocol)

I don't see the hook for protocol in https://schema.org/Action - can you explain what you meant?

[dr-shorthair]

@smrgeoinfo @ashepherd @mbjones @fils @njarboe this is possibly relevant to ESIPFed/science-on-schema.org#211