Add time range of observations in SOS for procedure to DescribeSensor

[GoogleCodeExporter]

To represent the time range of observations for a procedure in an SOS, we 
should add sml:validTime (
/sml:SensorML/sml:member/sml:System/sml:validTime/gml:TimePeriod...).

Description of valid time from OGC 07-000 SensorML 1.0.0 8.11.2.2:

    The validTime property indicates the time instance or time range over
    which this process description is valid. Time constraints are
    important for processes in which parameter values or operation modes
    may change with time.

Interpretation of what "valid" means is pretty open ended, but the property is 
intended for discovery and is part of OGC 09-033 OWS-6 SensorML Profile for 
Discovery Engineering Report.

Using sml:validTime to express the range of observation times is cleaner than 
using deployment history, since a sensor may include multiple deployments, be 
missing the deployment history, have a much longer deployment time than 
available observations in the database, etc.

This is already implemented in the 52 North SOS.

Original issue reported on code.google.com by sh...@axiomalaska.com on 22 Dec 2012 at 2:50

[GoogleCodeExporter]

Closing tomorrow (Friday 12/28/2012) pending any comments.

Original comment by srstcl...@gmail.com on 27 Dec 2012 at 9:01

[GoogleCodeExporter]

Added to Milestone 1.0 GetObs templates, closing.

Original comment by sh...@axiomalaska.com on 29 Dec 2012 at 12:27

• Changed state: Done

[GoogleCodeExporter]

I don't see how the validTime in the SML response can represent the range of 
observations.  As stated in 09-033 OWS-6 SensorML Profile for Discovery 
Engineering Report, "The validTime section provides information about the time 
period in which a sensor description is valid."  This represents the time for 
which this network/station/sensor configuration is valid -- not the time for 
which one should expect observations.  And yes, the time range for observations 
may very well be less than the sensor valid time.

Original comment by mike.gar...@gmail.com on 3 Jan 2013 at 7:36

[GoogleCodeExporter]

I agree that it's a stretch, but their definition is pretty vague. "the time 
period in which a sensor description is valid..." in what context? Globally? Or 
in the context of this server? It's not a prefect fit, I agree, but we needed 
to put the time range of observations somewhere, and the 52n developers 
recommended sml:validTime in relation to 09-033.

Were you planning on producing multiple SensorML documents for a station with 
different validTime ranges and different configurations? If this throws a 
wrench in your gears we could probably shift it back to some entries in 
sml:history or something, although it's not quite as clean.

Original comment by sh...@axiomalaska.com on 10 Jan 2013 at 10:32

[GoogleCodeExporter]

Original comment by sh...@axiomalaska.com on 10 Jan 2013 at 10:32

• Changed state: Accepted

[GoogleCodeExporter]

Any other thoughts, Mike or anyone else?

Original comment by sh...@axiomalaska.com on 18 Jan 2013 at 8:48

[GoogleCodeExporter]

The plan was to allow the end user to specify any deployment of a station using 
the version/date in the URN.  The SOS would then report the station 
configuration for that deployment.  Omitting the version would return the most 
recent deployment.

It seems to be a leap to use sml:validTime to express the range of observation 
times.  Unfortunately, I do not have an alternative solution at this time.

Original comment by mike.gar...@gmail.com on 18 Jan 2013 at 3:36

[GoogleCodeExporter]

Here is some pretty old document from the OGC Public Wiki that may help to 
better understand the sense of how <sml:validTime> is supposed to be used:

http://external.opengeospatial.org/twiki_public/NREwg/GMESPHInstrumentCapabiliti
es#ValidTime_Section

The 'validTime' section there is used to specify "a temporal validity time 
range that applies to the document. For Platform Capabilities and Instrument 
Capabilities documents, the validity period usually goes from the launch date 
to today (indicated by 'now') or the end of the life of the satellite. It can 
however be different if one of the on-board systems has limited functionality 
due to some incident. When an incident occurs, a new document can thus be 
created with a validity period going from the date of the incident to 'now'. 
The old document should be archived (perhaps for use with older products 
generated before the incident) with a validity period ending at the date of the 
incident."

That description seems closer to Mike's argument that <sml:validTime> is more 
about a lifetime of a platform or instrument, than about observation timeframe.

Just my $0.02...

Original comment by abir...@gmail.com on 18 Jan 2013 at 5:13

[GoogleCodeExporter]

I don't have anything new to add with respect to what interpretation of 
validTime is closest to the original intent. It seems like it could go either 
way.

However, I did want to address what Mike said in Comment 7, about the intent to 
"allow the end user to specify any deployment of a station using the 
version/date in the URN". I'd point out Issue 5 (closed months ago), 
http://code.google.com/p/ioostech/issues/detail?id=5, URN syntax for 
platform/stations identifiers; and the discussions linked from there. We had 
pretty extensive discussions about this over the Summer. The solution was not 
perfect, but it is reasonably clean. More to the point:
"2. The optional versioning string token described in the Geo-IDE wiki document 
will be eliminated, and should not be used."

Until there is a more extensive revisit of this issue, I would strongly vote 
for not reopening this, and not planning to add a version or date to urn's for 
now. As you can see from those discussion, there are lot of tricky 
ramifications. Let's stick to what we decided, until we've truly reached 
Milestone 1 (or 1.1? Whatever) and have the opportunity to dedicate real 
braintrust to this issue.

Original comment by emilioma...@gmail.com on 19 Jan 2013 at 2:08

[GoogleCodeExporter]

Ok, I'm convinced. I'll be out for two weeks, but when I get back I'll propose 
a different location to indicate the time range of observations in the SOS 
(probably just a metadata tag, since there doesn't seem to be any better place 
for them). If anyone wants to make a suggestion in the interim, please do so. 
sml:validTime will return to its regularly scheduled programming...

Original comment by sh...@axiomalaska.com on 28 Jan 2013 at 11:16

• Changed title: Add time range of observations in SOS for procedure to DescribeSensor

[GoogleCodeExporter]

Original comment by dpsnowde...@gmail.com on 30 Jan 2013 at 5:16

• Added labels: Priority-High

[GoogleCodeExporter]

Waiting anxiously for an alternative to validTime

Original comment by wilcox.k...@gmail.com on 31 Jan 2013 at 4:56

[GoogleCodeExporter]

We'll open another issue for Shane's issue.  Also, the templates must be 
changed so that the comment above the validTime element is correct.  The use of 
the element is ok, the comment is wrong.

Original comment by dpsnowde...@gmail.com on 31 Jan 2013 at 4:59

• Changed state: Done

[GoogleCodeExporter]

I updated the templates, all set.

Original comment by wilcox.k...@gmail.com on 31 Jan 2013 at 5:00