search

valentinedwv / ioostech

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

Consider using swe:Category over swe:Text #22

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago 
We have:

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

Should we have?:

<swe:field name="station_id">
  <swe:Category codeSpace="http://fixme.vocab/station_dictionary">
    <swe:value>urn:ioos:station:wmo:41012</swe:value>
  </swe:Category>
</swe:field>

Here is a note from the SWE 2.0 spec that lead me to this:
"
Note: The “Text” component can be used to wrap a string representing 
complex content such as an expression in a programming language, xml or html 
content. This practice should however be used only for systems that don’t 
require high level of interoperability since the client must know how to 
interpret the content.
"

Using the Category approach would require a dictionary of allowed values.  SOS 
2.0 again, regarding <swe:Category>:

"
However, as the intent of this class is to always represent a value extracted 
from a set of possible options, a constraint shall be defined if no code space 
is specified.

An instance of the “Category” class shall either specify a code space or an 
enumerated list of allowed tokens, or both.
"

Original issue reported on code.google.com by wilcox.k...@gmail.com on 5 Jun 2012 at 8:30

GoogleCodeExporter commented 8 years ago 
Strictly speaking, station id isn't a category, at least not if we interpret a 
category as a qualifier. But the SWE 1.0 description of swe:Category isn't 
highly prescriptive:
8.1.3 Category
Category represents textual data that is a member of some larger grouping of 
values. The type of category is defined by the definition attribute (e.g., 
“dog” may be the value of a category defined by “mammal”), while the 
codeSpace provides a dictionary of potential values. Category usually takes a 
token (i.e., simple string) as its value. A Category can also have a constraint 
that further limits its potential value to being a member of an enumerated list 
of tokens. The quality of a Category would typically be a Quantity or a 
Category indicating the level of confidence in the classification.

A dictionary of allowed values is not required.

My suggestion is to retain swe:Text for now and revisit this in the future, 
after Milestone 1. Seems harmless, and no clear and unambiguous gain from 
switching to swe:Category.

Original comment by emilioma...@gmail.com on 6 Jun 2012 at 3:19

GoogleCodeExporter commented 8 years ago 
I don't feel especially strongly either way, but I don't think I like the idea 
of having to maintain a list of stations, sensors, etc outside of the SOS. In 
our case it might be ok that "the client must know how to interpret the 
content." They're going to have to understand the id encoding scheme if they 
want to parse the ids anyway, and it seems better to me to reference the 
general format in swe:Text's definition than a definitive list in 
swe:Category's codeSpace.

Original comment by sh...@axiomalaska.com on 8 Jun 2012 at 3:53

GoogleCodeExporter commented 8 years ago 
I agree with Shane 100%.

So, the proposed resolution is: Let's not change anything, and we will retain 
swe:Text for Milestone 1.

Original comment by emilioma...@gmail.com on 8 Jun 2012 at 6:20

GoogleCodeExporter commented 8 years ago 
+1 to close and leave as Text.  Are we actually closing these issues?

Original comment by wilcox.k...@gmail.com on 12 Jun 2012 at 2:34

GoogleCodeExporter commented 8 years ago 
[deleted comment]
GoogleCodeExporter commented 8 years ago 
We are closing issues, yes. And it's *fun* to do it! Such a feeling of 
accomplishment...

Original comment by emilioma...@gmail.com on 12 Jun 2012 at 2:50