]> An example of the SSN-XG sensor ontology (http://www.w3.org/2005/Incubator/ssn/) used to describe a sensing device - the Vaisala WM30. The Vaisala WM30 measures wind speed and wind direction. The device data sheet is available at http://www.vaisala.com/en/products/windsensors/Pages/WM30.aspx The specification here follows the data sheet closely and describes all the measurement capabilites, power supply and operating and survial properties. This example shows how to use and build on the definitions in the SSN-XG's ontology as well as how to import and use other ontologies (in this example units) and how to extend the definitions. There are things about a sensor that one may wish to describe that aren't covered by this example (or the SSN-XG ontology). For example, data about the company that made the device, the url of documentation, the size and weight of the device, etc. These aren't sensor specific issues and so aren't covered, one needs to import other approapriate ontologies to describe those aspects. Also, this example doesn't provide any instance specifications - it describes what a WM30 is, not any particular WM30 devices. Generally an ontology like this one would describe the TBox specification and the ABox instances provided by a separate ontology; hence the instances are in an acompaning example. The WM30 is a device (a piece of hardware and embedded software 260x300mm) that measures both wind speed and wind direction. For the purposes of the example, we are underspecifying the two main parts of the WM30. The specification isn't concerned if the wind speed and direction sensors are devices or not. If they were separable from the WM30 and usable separately they should probably be modelled as devices. As it stands the WM30 is a device with two sensing capabilities that aren't separable from the device; hence the are just modelled as sensors that implement sensing (the use of hasSubSystem means they must be Systems, which is fair enough as they are pieces of technology). The WM30's characteristic transfer function is the formula used by the device to relate the turning of the cups to windspeed: i.e. it's really the method of measurement used. That's why it specified here as a sensing method. The actual transducer in the device outputs hertz and the WM30 converts this to WindSpeed via the function. Thus another modelling option would be to model the whole chain (subdivide the WM30 into further component and show how the output of the transducer is the input of the characteristic transfer function, etc) indicating more closely how the device actually makes the measurement. For this example that's not really necessary. There are any number of ways to specify the characteristic transfer function. DUL's information objects and realisations could be used provide some other concrete description. If we had an application that needed to read in the function, perhaps if the specification was of an abstract sensor that needed to be realised at runtime, then some systematic standard or format should be used - technically though anything could be attached: formated text, a reference to a scientific paper describing the measurement process, MathML, an algorithm specification in a formal language, program code or an executable. 15.0 3.0 55.0 -40.0 65.0 -60.0 This is called 'Storage temperature' on the WM30 data sheet. The intention is likely to be the same as SurvivalRange: i.e. if the device is stored outside this temperature range it no longer works as specified. In any case, for the purposes of the example it shows the use of SurvivalRange. The WM30 can be purchased with one of two options for its wind direction sensor. The WMS301 has one wiper, while the WMS302 has two, and thus a greater measurement range. 0.6 0.3 0.4 1.0 3.0 -3.0 Similarly to the wind speed capabilities, the definitions approapriate to both the WMS301 and the WMS302 are specified here and inherited by the subconcepts. 355.0 0.0 360.0 0.0 The WindSpeed sensor of the WM30. It implements a known formula for relating the spinning of the cups to windspeed and has different accuracies in different conditions. 1.0 0.7 0.4 2.0 The WM30 will have two measurement capabilities, one for each of the subconcepts here. The specifications applicable to both are made here and inherited by the subconcepts. The transducer output could perhapse be better modelled with a structure that is more easily recognised at 1 Hz per 0.7 m/s, but as it is looks sufficient. The MeasurementRange of the WM30 can be infered as the combined ranges of the two capabilites. Another way to do it would be to provide a third capability of the WM30 that specifies only the MeasurementRange. 60.0 10.0 2.0 -2.0 3.0 -3.0 10.0 0.4 Characteristic transfer function U = -0.24 + 0.699 × F (where U = wind speed [m/s], F = output frequency [Hz])