[SensorML] standard sensornames ?
Simon.Cox at csiro.au
Simon.Cox at csiro.au
Wed Jul 2 01:30:16 EDT 2008
Re the GCMD lists: isn't this *propertyTypes* rather than "sensorTypes".
Many sensor types can measure the same property.
Simon.Cox at csiro.au CSIRO Exploration & Mining
26 Dick Perry Avenue, Kensington WA 6151
PO Box 1130, Bentley WA 6102 AUSTRALIA
T: +61 (0)8 6436 8639 Cell: +61 (0) 403 302 672
Polycom PVX: 22.214.171.124
ABN: 41 687 119 230
> -----Original Message-----
> sensorml-bounces+simon.cox=csiro.au at lists.opengeospatial.org
> [mailto:sensorml-bounces+simon.cox=csiro.au at lists.opengeospati
> al.org] On Behalf Of John Graybeal
> Sent: Wednesday, 2 July 2008 1:30 AM
> To: gsnmlxs
> Cc: sensorml
> Subject: Re: [SensorML] standard sensornames ?
> One must distinguish between the _name_ of the sensor --
> presumably a unique name, so you can distinguish that sensor
> from any other sensor, even those 'just like it' -- and the
> chacterization of the sensor, as for example by providing a
> "sensor type" like Soil Moisture Sensor.
> The former -- a name for a sensor -- can be an arbitrary
> string, but best practices dictate a unique string, in a
> controlled and defined namespace. Obviously unique names are
> most trivially created/named as URLs (because you know your
> own http domain should be unique), though the OGC practice is
> to use URNs in most situations.
> The latter -- a sensor type, or a feature type -- relies on
> the existence of a controlled vocabulary that lists the
> possible names you can use (or describes how to create a new
> name). The controlled vocabulary may be a community
> vocabulary, or may be one of your own creation. The key
> features of such a vocabulary are that each term has a
> definition, changes are tracked, and unique URIs can be
> generated for each term. GCMD has a long set of terms that
> approximate sensor types, and may be sufficient for finding
> the term (MMI hopes to create corresponding URIs for those,
> in the next 6-8 months), but a more definitive community
> vocabulary would be better. MMI is trying to create such a
> vocabulary for marine sensors; I am not aware of any
> equivalent in terrestrial sensing, but they may exist.
> Features can be found in the SWEET ontology, though again
> I'm not sure about existing URIs for that ontology.
> Some of the SensorML examples that are illustrative are on
> the VAST web pages; see for example .
> MMI and OOSTethys/Oceans IE are in the process of
> developing some more concrete best practices and examples for
> these kinds of naming, URI generation, and feature/sensor
> terminology issues. As you can perhaps tell, solutions that
> are sensor-web-aware are still very much in development.
>  MMI: Marine Metadata Interoperability Project
> (http://marinemetadata.org)  OOSTethys Project
> (http://oostethys.org)  Oceans IE: OGC Oceans
> Interoperability Experiment
>  MMI Device Ontology Working Group
>  SWEET: Semantic Web for Earth and Environmental
> Terminology (http://sweet.jpl.nasa.gov/ontology/)
>  MBARI CTD Buoy XML in SensorML
> At 12:20 PM -0400 7/1/08, gsnmlxs wrote:
> >Hi all,
> >I have similar question. The schema contains a lot of fileds
> some of which (mainly come from GML) may not be necessary in
> most of cases. I am wondering if there is a standard
> specification on what information items are necessary or
> optional. Otherwise I think it is still difficult for the
> interoperation. Let me know your great ideas!
> >Best wishes,
> >FromÅF Aadit Shrestha
> >AtÅF 2008-07-01 09:19:01
> >ToÅF sensorml at lists.opengeospatial.org
> >SubjectÅF [SensorML] standard sensornames ?
> >Dear all,
> >Are there any standard methods to write sensornames and phenomenons?
> >For Example if I want to write 'Soil Moisture Sensor', how
> do I write it?
> >'Soil_Moisture' or 'SoilMoisture' or 'SM' or 'S M Sensor'
> etc Is there
> >a standardized list of how sensornames and phenomenon names
> should be written? ... So that they are unique and
> distinguished globally?
> >Thanks and regards,
> >SensorML mailing list
> >SensorML at lists.opengeospatial.org
> John Graybeal <mailto:graybeal at mbari.org> -- 831-775-1956
> Monterey Bay Aquarium Research Institute Marine Metadata
> Interoperability Project: http://marinemetadata.org Shore
> Side Data System: http://www.mbari.org/ssds
> SensorML mailing list
> SensorML at lists.opengeospatial.org
More information about the SensorML