search

valentinedwv / ioostech

Automatically exported from code.google.com/p/ioostech
0 stars 0 forks source link

Decide where to put the concept of a StationID and SensorID #14

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago 
Mike Garcia raised the question about how we should represent Station and 
Sensor IDs in the responses

Original issue reported on code.google.com by wilcox.k...@gmail.com on 21 Mar 2012 at 7:14

GoogleCodeExporter commented 8 years ago 
You may view the SWE samples at http://sdftest.ndbc.noaa.gov/sos/ to see how we 
have added station and sensor ids to the responses.  These responses are a 
first attempt and feedback is invited.

Original comment by mike.gar...@gmail.com on 21 Mar 2012 at 7:40

GoogleCodeExporter commented 8 years ago

Original comment by dpsnowde...@gmail.com on 18 Apr 2012 at 3:28

GoogleCodeExporter commented 8 years ago

Original comment by dpsnowde...@gmail.com on 24 Apr 2012 at 1:57

GoogleCodeExporter commented 8 years ago 
Station:

<swe:field name="station_id">
  <swe:Text definition="http://fixme.vocab/station">
    <swe:value>urn:ioos:station:wmo:41001</swe:value>
  </swe:Text>
</swe:field>

Sensor: 
<swe:field name="sensor_id">
  <swe:Text definition="http://fixme.vocab/sensor">
    <swe:value>urn:ioos:sensor:wmo:41001::baro1</swe:value>
  </swe:Text>
</swe:field>

Original comment by wilcox.k...@gmail.com on 24 Apr 2012 at 3:01

GoogleCodeExporter commented 8 years ago 
Well, apparently, you can't edit comments.

Above is what NDBC has implemented.  Aside from figuring out what the 
"definition" should reference, it looks to me like: 
https://geo-ide.noaa.gov/wiki/index.php?title=IOOS_Conventions_for_Observing_Ass
et_Identifiers.

Are there any objections to using the IOOS asset identifier conventions?

Since those conventions are DRAFT, we need to make a more concrete decision.

Original comment by wilcox.k...@gmail.com on 24 Apr 2012 at 3:10

GoogleCodeExporter commented 8 years ago 
At the workshop we agreed to using the current urn scheme so I think that 
question is settled for now.

But we also acknowledged that we need some modifications to it. 
1. We needed to add guidance for the appropriate URN to identify a procedure 
that describes a network.  
2. We need a discussion of when and how to move from URN to URLs.  I suggest a 
new issue and a milestone of v2.0 not 1.0 so that we don't forget it but it's 
also not something we need to worry about now.
3. As a corollary to 2, we need to address the definition element that Kyle 
mentioned.  The geo-ide wiki is one solution but there are also several 
existing vocabularies and ontologies that document various aspects.  (e.g. 
http://mmisw.org/orr/#http://mmisw.org/ont/mmi/platform)  In my mind the 
question is, is the "definition" attribute pointing to the definition of the 
term or concept called "platform" (or sensor or station).  Or, is it pointing 
to the syntax of the particular URN scheme we chose to encode station 
identifiers?  If the answer is the former, then we go down the ontology road, 
if it is the latter then we can use the geo-ide wiki for now.

Original comment by dpsnowde...@gmail.com on 24 Apr 2012 at 4:24

GoogleCodeExporter commented 8 years ago 
Separate issue for URN -> URL migration sounds good.

> In my mind the question is, is the "definition" attribute pointing to the
> definition of the term or concept called "platform" (or sensor or station).  
Or, 
> is it pointing to the syntax of the particular URN scheme we chose to encode 
> station identifiers?  If the answer is the former, then we go down the 
ontology 
> road, if it is the latter then we can use the geo-ide wiki for now.

It seems more useful to me to use the URN scheme definition as the swe:Text 
definition. This would allow us to link to a single definition doc that 
described the hardened URN standard and optionally included ontological links 
to terms like sensor, station, network, etc. The SWE standard suggests that 
either approach is ok (one example links to the definition of a Manufacturer, 
one links to the definition of ModelID).

Original comment by sh...@axiomalaska.com on 24 Apr 2012 at 5:59

GoogleCodeExporter commented 8 years ago 
I agree with Shane: let's go with the URN scheme definition document (the 
GEO-IDE wiki page) as the swe:Text definition for Milestone 1.0.

> 2. We need a discussion of when and how to move from URN to URLs.
> I suggest a new issue and a milestone of v2.0 not 1.0

Also agree with Derrick and Shane on making this a v2.0 issue. Let's not bother 
too much with a discussion on this until 1.0 is reached.

> 1. We needed to add guidance for the appropriate URN to identify 
> a procedure that describes a network.

I'm not sure we reached sufficient consensus and discussion of all 
ramifications to feel confident that this can be a 1.0 issue. My hunch is that 
we should not make it an official 1.0 issue, but still have a proposed draft 
implementation when 1.0 is reached. But maybe I'm off and we really can make it 
a 1.0 issue??

Regarding Kyle's dump of the SWE blocks for station and sensor ID definitions 
in the NDBC test SOS (thanks, Kyle): eg, for a sensor:
urn:ioos:sensor:wmo:41001::baro1
This looks to me like it doesn't follow the syntax/convention laid out here:
https://geo-ide.noaa.gov/wiki/index.php?title=IOOS_Conventions_for_Observing_Ass
et_Identifiers
According to that page, it should be:  urn:ioos:sensor:wmo:41001:baro1  (no 
double colon)

The examples used on the IOOS CSV/TSV encoding page also seem inconsistent:
https://geo-ide.noaa.gov/wiki/index.php?title=IOOS_Conventions_for_CSV_and_TSV_E
ncoding
eg:
urn:ioos:station:wmo:41012:,urn:ioos:sensor:wmo:41012::watertemp1:
According to the IOOS urn convention page, the NDBC SWE definition blocks, and 
all existing usage I'm aware of, the station and sensor urn's never end in ":".

Finally, since this is the time to finalize these conventions, a 
comment/question at
https://geo-ide.noaa.gov/wiki/index.php?title=IOOS_Conventions_for_Observing_Ass
et_Identifiers#Sensor_Identifiers
asks if the "sensor" asset type is redundant. The questions posed seem 
appropriate. They should be resolved (eg, ignored) before we call it final.

Original comment by emilioma...@gmail.com on 24 Apr 2012 at 7:15

GoogleCodeExporter commented 8 years ago 
I agree, the way I read it is that identifiers shouldn't end with a colon and 
shouldn't have double colons.

Is there a suggestion on where the finalized IOOS identifier definitions could 
be hosted? Seems like MMI holds only vocabularies and mappings.

How about this for the network format? I don't think a single network 
identifier should try to capture a full network hierarchy.

Network:
<swe:field name="network_id">
  <swe:Text definition="http://home.of.ioos.conventions/network">
    <swe:value>urn:ioos:network:aoos:all-barometric</swe:value>
  </swe:Text>
</swe:field>

Station:
<swe:field name="station_id">
  <swe:Text definition="http://home.of.ioos.conventions/station">
    <swe:value>urn:ioos:station:wmo:41001</swe:value>
  </swe:Text>
</swe:field>

Sensor: 
<swe:field name="sensor_id">
  <swe:Text definition="http://home.of.ioos.conventions/sensor">
    <swe:value>urn:ioos:sensor:wmo:41001:baro1</swe:value>
  </swe:Text>
</swe:field>

Original comment by sh...@axiomalaska.com on 3 May 2012 at 5:55

GoogleCodeExporter commented 8 years ago 
Ah, after looking at the DescribeSensor templates I see that network is more 
complicated than that, with parentNetworks and networkOfferings, etc. Seems 
like that should be its own issue.

Original comment by sh...@axiomalaska.com on 3 May 2012 at 6:11

GoogleCodeExporter commented 8 years ago 
Right or wrong, the double-colon is a place holder for an optional station 
version.  Both stations and sensors may have versions.  These are not 
implemented at this time, but the intent was for the version to represent the 
deployment date (YYYYMMDD) of the station and the install date of the sensor 
(YYYYMMDD).  When omitted, the service would return the most recent 
version/deployment/installation.

URNs would be something like this...
urn:ioos:station:wmo:41001:20110213
urn:ioos:sensor:wmo:41001:20110213:baro1:20120110

-- or --

urn:ioos:station:wmo:41001
urn:ioos:sensor:wmo:41001::baro1

Original comment by mike.gar...@gmail.com on 3 May 2012 at 2:41

GoogleCodeExporter commented 8 years ago 
[deleted comment]
GoogleCodeExporter commented 8 years ago 
Ah, ok. If we go this route, it seems like an identifier with an omitted 
station version could be considered a kind of virtual parent procedure, meaning:

urn:ioos:station:wmo:41001
is a parent of 
urn:ioos:station:wmo:41001:20110512 and
urn:ioos:station:wmo:41001:20090602

and 

urn:ioos:sensor:wmo:41001::baro1
is a parent of
urn:ioos:sensor:wmo:41001:20110512:baro1 and
urn:ioos:sensor:wmo:41001:20090602:baro1

I was a little concerned about having to translate procedure identifiers in an 
IOOS specific way, but handling them as parent procedures would eliminate the 
need to do so (and simplify implementation for SOSs that don't include 
deployment information in the procedure identifier).

Edit: fixed sensor example.

Original comment by sh...@axiomalaska.com on 3 May 2012 at 5:24

GoogleCodeExporter commented 8 years ago 
The concept of parent ID is at odds with the way the original conventions were 
drafted.  See the geo-ide referenced above for more info.  The particular text 
from the "versions" section of the wiki is:

If an identifier has one or more values with version numbers, then a value 
without the version must also exist, and the unversioned value must refer to 
the most recent version. For example, if urn:ioos:platform:foo:a:1 and 
urn:ioos:platform:foo:a:2 both exist, then urn:ioos:platform:foo:a must refer 
to the same asset as urn:ioos:platform:foo:a:2. 

So, the unversioned URN isn't a parent so much as the most recent instance.  
Are these two concepts incompatible?

Before we go too far down the road of building software around the semantics of 
URN schemes, we should make sure it's necessary.

Finally, the concept of unversioned URIs pointing to the most recent resource 
is consistent with other semantic frameworks.  At the MMI OR & R the following 
two URIs point to the same resource...

http://mmisw.org/ont/cf/20120323T163922/parameter/sea_water_temperature
http://mmisw.org/ont/cf/parameter/sea_water_temperature

ahem, one of them isn't working now but you get the idea.

Original comment by dpsnowde...@gmail.com on 3 May 2012 at 6:28

GoogleCodeExporter commented 8 years ago 
> So, the unversioned URN isn't a parent so much as the most recent instance.  
Are these two concepts incompatible?

In practice I think the main difference would be that an unversioned identifier 
implemented as a parent could refer to more than one versioned identifier. For 
example if you requested all observations from urn:ioos:platform:foo:a you 
would get back all observations from both urn:ioos:platform:foo:a:1 and 
urn:ioos:platform:foo:a:2. If the unversioned identifier is instead treated as 
an alias for the most recent version, you would only get 
urn:ioos:platform:foo:a:2 back.

Treating unversioned identifiers as parents seems more intuitive from a user's 
perspective to me, and would be easier to implement (for me at least). However, 
I'm no sensor expert and there may be very good reasons for treating 
unversioned identifiers as pointers, especially considering this was previously 
codified in the geo-ide wiki. What do others think?

Original comment by sh...@axiomalaska.com on 3 May 2012 at 6:39

GoogleCodeExporter commented 8 years ago 
Note issue #22 on use of swe:Category over swe:Text

Original comment by wilcox.k...@gmail.com on 5 Jun 2012 at 8:31

GoogleCodeExporter commented 8 years ago 
Two things. First, the IOOS conventions page 
(https://geo-ide.noaa.gov/wiki/index.php?title=IOOS_Conventions_for_Observing_As
set_Identifiers) lists this as the general asset identifier format: 

urn:ioos:asset_type:authority:label[:component][:version]

However, all the examples we've been working with actually have this format 
(component and version are switched):

urn:ioos:asset_type:authority:label[:version][:component]

e.g. urn:ioos:sensor:wmo:42001::wpm1

Q1: Should the IOOS page be corrected?

Second, we need to address the unversioned parent procedure question.

Q2: Should an unversioned parent procedure (station/platform) be an alias for 
a) all versions of the station, or b) only the most recent version of the 
station?

Please vote if you have an opinion, or let us know if the questions need 
adjustment.

I vote Q1 yes and Q2 a) all versions.

Original comment by sh...@axiomalaska.com on 8 Jun 2012 at 4:02

GoogleCodeExporter commented 8 years ago 
See this ioostech_dev thread where I (and Derrick) tried to outline decisions 
on outstanding issues regarding the urn conventions:
https://groups.google.com/d/topic/ioostech_dev/F1SBuamGUrI/discussion
These are tentative for the next couple of days, while we reach sufficient 
agreement.

* Regarding your Q1: Yes, but not yet. Once we truly finalize the urn 
conventions, I'll draft an ioostech wiki page on this topic alone. At that 
point we can start proposing revisions to the IOOS Geo-IDE wiki page

* Regarding Q2: As we discussed in that email thread I pointed out, the 
proposal on the table (mainly from me, but with Derrick's acceptance, though 
somewhat kicking and screaming) is to remove the version code altogether from 
the urn convention. ie:
  urn:ioos:asset_type:authority:label[:component] 
If we go with this recommendation, Q2 will become moot.

Original comment by emilioma...@gmail.com on 8 Jun 2012 at 11:23

GoogleCodeExporter commented 8 years ago 
The discussion on this Issue ended up expanding to include urn conventions, 
which was already the focus of Issue 5 
(http://code.google.com/p/ioostech/issues/detail?id=5). We've resolved urn 
conventions, and the decisions have been documented on Issue 5, which has now 
been closed.

Please don't add more discussions on urn conventions here, as that would only 
confuse things. Further discussions here should focus on the original scope of 
this Issue: "How to represent (or where to put) Station and Sensor IDs in SOS 
responses."

Network ID has been discussed here as well. Network procedures have additional, 
unique ramifications. Therefore, we may decide to expand this issue to include 
Network ID, or create a separate, focused issue.

Original comment by emilioma...@gmail.com on 15 Jun 2012 at 6:28

GoogleCodeExporter commented 8 years ago 
Issue is ready to be closed. Here's a summary of decisions:

- Supported ids are network, sensor, and station. Platform is not a supported 
id.
- Formats:
-- Station: urn:ioos:station:wmo:41001
-- Sensor: urn:ioos:sensor:wmo:41001:baro1
-- Network: urn:ioos:network:aoos:all-barometric
- Version (deployment date, etc) is not included in the URN standard at this 
time. The wiki needs to be updated to reflect this.

References:
http://code.google.com/p/ioostech/issues/detail?id=14
https://groups.google.com/forum/#!topic/ioostech_dev/F1SBuamGUrI/discussion

Closing on Friday 12/28/2012 pending comments.

Original comment by srstcl...@gmail.com on 27 Dec 2012 at 10:02

GoogleCodeExporter commented 8 years ago 
Closing issue, rule added to guidelines:

http://code.google.com/p/ioostech/wiki/SOSGuidelines_final#Asset_URN_identifiers

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

GoogleCodeExporter commented 8 years ago 
I happen to be looking at this, and just wanted to update the guideline URL 
listed in the last comment (#21); that URL is out of date, and the new URL is:
https://code.google.com/p/ioostech/wiki/SOSGuidelines#Asset_URN_identifiers

Original comment by emilioma...@gmail.com on 27 Sep 2013 at 4:15