In IOOS SOS, how to include assets/variables that offer no data?

[Emilio Mayorga]

In developing the IOOS SOS Milestone 1 (and 1.x/2), there's a use case that I don't remember seeing in our discussions, but may be fairly useful or important; specially considering that these SOS end points will also be used for the IOOS asset inventory (https://code.google.com/p/ioostech/wiki/AutomatedAssetInventory).

How do we represent station assets that have no associated data (observations) available via the SOS service? In other words, in the GetObservation request for that station, the swe2:values block (om:result/swe2:DataRecord/swe2:field/swe2:DataArray/swe2:values) would be empty. Alternatively, some of the station variables may have data available, some may not. But there may be enough metadata to provide complete, compliant GetCapabilities and DescribeSensor responses.

This boils down to how to specify a station asset or variable within an asset in a GetCapabilities response, to give useful information while explicitly indicating that a corresponding GetObservation request won't return any data?

I have two different instances of this use case:
1. The SOS service provider may have complete asset catalog information (say, to a long time series that is either ongoing or has ended), but hasn't ever ingested the actual data such that it can be reserved. The data may reside in funky data files freely available at a URL that could be included in the SOS responses.
2. The SOS service provider does have complete access to the data; let's say it's a near-real-time data stream. But the data owner has asked that the data are not reserved or made available for direct download, due to special sensitivities.

These are not idle scenarios. NANOOS has two important instances of #2, that we'd like to make discoverable through IOOS national catalog/registry efforts. And I'm sure most of us have some version of #1.

Thoughts? If there's interest we can also discuss this at the DMAC meeting next week, officially or unofficially.

Looking forward to seeing many of you next week. Cheers,
-Emilio

[Alexander Birger]

Emilio,

 

I believe that we may take care of case #1 by use of an <sos:Capabilities/sos:Contents/sos:ObservationOfferingList/sos:ObservationOffering/responseMode> optional element. One of the values allowed for that element is “out-of-band”, which lets data consumer know right away that the data will not be returned via GetObservation; instead, the URL to some file may be returned.

 

For the case #2, a similar approach may be used but the referred file may contain a detailed explanation of the data sensitivity, ways of getting data, etc. It looks a little stretchy but it is the first that came into mind.

 

Alex Birger
Systems Engineer

Skjei Telecom

7777 Leesburg Pike, Suite 315N
Falls Church, VA 22043

Direct:   +1 703 917 9889

Main:    +1 703 917 4077

Fax:       +1 703 917 0098
e-mail: alex....@skjeitelecom.com

My availability: http://www.timebridge.com/mytime/alexanderbirger

 

CONFIDENTIALITY NOTICE: For intended Skjei Telecom recipients only.

--
--
You received this message because you are subscribed to the Google
Groups "ioostech_dev" group.
To post to this group, send email to iooste...@googlegroups.com
To unsubscribe from this group, send email to
ioostech_dev...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/ioostech_dev?hl=en
 
---
You received this message because you are subscribed to the Google Groups "ioostech_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ioostech_dev...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Emilio Mayorga]

Alex,

Thanks for the input. Very useful. Hopefully we'll have a chance to talk a bit about this at the DMAC meeting next week, both to flesh out of what you've proposed and to see if there are other suggestions.

Cheers,

-Emilio