[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: 130.116.146.28
<http://www.csiro.au>

ABN: 41 687 119 230
 

> -----Original Message-----
> From: 
> 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[1] is trying to create such a 
> vocabulary for marine sensors[4]; I am not aware of any 
> equivalent in terrestrial sensing, but they may exist.  
> Features can be found in the SWEET ontology[5], 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 [6].
> 
> MMI and OOSTethys[2]/Oceans IE[3] 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.
> 
> [1] MMI: Marine Metadata Interoperability Project 
> (http://marinemetadata.org) [2] OOSTethys Project 
> (http://oostethys.org) [3] Oceans IE: OGC Oceans 
> Interoperability Experiment 
> (http://xml.coverpages.org/OGC-oceansie.html)
> [4] MMI Device Ontology Working Group 
> (http://marinemetadata.org/ontdev)
> [5] SWEET: Semantic Web for Earth and Environmental 
> Terminology (http://sweet.jpl.nasa.gov/ontology/)
> [6] MBARI CTD Buoy XML in SensorML 
> (http://vast.uah.edu/index.php?view=article&catid=61%3Amarine-
> sensors&id=130%3Ambari-buoy-system&option=com_content&Itemid=75)
> 
> John
> 
> 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,
> >
> >Pine
> >2008-07-01
> >
> >FromÅF Aadit Shrestha
> >AtÅF 2008-07-01 09:19:01
> >ToÅF sensorml at lists.opengeospatial.org
> >CCÅF
> >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,
> >Aadit
> >
> >
> >_______________________________________________
> >SensorML mailing list
> >SensorML at lists.opengeospatial.org
> >https://lists.opengeospatial.org/mailman/listinfo/sensorml
> 
> 
> --
> ----------
> 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
> https://lists.opengeospatial.org/mailman/listinfo/sensorml
> 



More information about the SensorML mailing list