- From: Michael Compton <Michael.Compton@csiro.au>
- Date: Tue, 20 Apr 2010 15:31:30 +1000
- To: Michael Compton <Michael.Compton@csiro.au>
- CC: "public-xg-ssn@w3.org Group WG" <public-xg-ssn@w3.org>
Thanks Luis and Carlos. I've also sent out my example. This is also a response to http://marinemetadata.org/community/teams/ontdevices/devontacc I made my example use the same sort of structure for ranges as this so that the only real difference was in the modelling of accuracy etc. Though there is another difference because I used Condition to model the constraint on accuracy rather than a measurement range. It's not really important for this example but if the constraint was something other than the quality being measured something like this is required. I'd intended in my model that all the named things be properties of the sensor itself and condition to be 'prevailing conditions' or the qualities that affect this measurement: i.e. external physical conditions. For this example I think Luis's model looks fair enough. Though I'm not sure how to interpret the indirection: i.e. could I write it any way around with the range having condition accuracy. In general, thought, it seems a bit strange to refer to one capability as a condition for another. My main objection is that as specifications get more complicated this approach seems to get more convoluted. For example, it's not always the case that capabilities are affected by external factors, sometimes you can get different precision say based on latency (e.g. http://datasheets.maxim-ic.com/en/ds/DS1722.pdf see page 6). So let's assume a device like the DS1722 where different latencies give different precisions and that each of those precisions has a different accuracy associated with it and that each has a different possible measurement range (i.e. as we wait longer we get more bits in the result, the result gets more accurate and the range of measurement is extended). How are we to model such a device? There would be loads of orderings and combinations of the hasConditions and that would seem to make for awkward queries and modelling. It also seems that these factors are a tuple - i.e. the latency is as much a condition of the accuracy as the accuracy is a condition on the latency - so the hasConditions relations here don't seem to represent the natural way to think about the relationship of these capabilities to each other. So while I think that Luis's proposal will work and can be extended to cover these sorts of ideas, I still think representing these things in a tuple is a more concise and faithful way to model sensors' capabilities. Thanks, Michael On 20/04/2010, at 14:31 , Michael Compton wrote: > Just checking if the tracker will pick this up > > > Begin forwarded message: > >> From: Luis Bermudez <bermudez@sura.org> >> Date: 17 April 2010 Sat [Apr 17] 12:15:06 AM >> To: "Neuhaus, Holger (ICT Centre, Hobart)" <Holger.Neuhaus@csiro.au> >> Cc: "public-xg-ssn@w3.org" <public-xg-ssn@w3.org> >> Subject: Re: SSN-XG Meeting Minutes 13 March 2010 >> Reply-To: "bermudez@sura.org" <bermudez@sura.org> >> >> Michael, et. al., >> >> We have been discussing at the MMI device ontology group the issue >> related to the measurement capabilities. >> >> here is the proposed approach: >> >> A Measurement Capability hasCondition another Measurement Capability. >> >> So if we have: >> >> Accuracy (range 0.4...60 m/s) >> wind speed up to 10 m/s -- ±0.3 m/s >> wind speed over 10 m/s -- error < 2% >> >> we can say >> >> instrumentA hasMeasurementCapability WindSpeedRangeA >> where WindSpeedRangeA is (0 - 10 /ms) >> >> instrumentA hasMeasurementCapability AccuracyA >> where AccuracyA is (range 0.4...60 m/s) >> and: >> AccuracyA hasCondition WindSpeedRangeA >> >> >> Comments ? >> >> - Luis >> >> >> >> >> On Tue, Apr 13, 2010 at 7:48 PM, <Holger.Neuhaus@csiro.au> wrote: >>> Hi all, >>> >>> Thank you for attending the telephone conference yesterday. >>> >>> The minutes can be found here: http://www.w3.org/2010/04/13-ssn-minutes.html >>> >>> >>> Summary of Action Items >>> >>> [NEW] ACTION: kerry to adjust wiki and report to W3C [recorded in >>> http://www.w3.org/2010/04/13-ssn-minutes.html#action02] >>> [NEW] ACTION: kierry to adjust wiki and report to W3C [recorded in >>> http://www.w3.org/2010/04/13-ssn-minutes.html#action01] >>> [NEW] ACTION: Luis to extend the MMI example with measurement >>> capabilities >>> with conditions [recorded in >>> http://www.w3.org/2010/04/13-ssn-minutes.html#action03] >>> [NEW] ACTION: Michael to report on EGU presentation to be delivered >>> by Simon >>> [recorded in http://www.w3.org/2010/04/13-ssn-minutes.html#action05] >>> [NEW] ACTION: Michael to upload the RDF corresponding the the wiki >>> page >>> example [recorded in http://www.w3.org/2010/04/13-ssn-minutes.html#action04 >>> ] >>> >>> >>> >>> Please close your actions in the issue tracker once they’re >>> completed. >>> >>> >>> >>> >>> >>> Cheers, >>> >>> Holger >>> >>> >>> >>> Dr. Holger Neuhaus >>> Postdoctoral Fellow >>> Tasmanian ICT Centre >>> CSIRO >>> >>> Phone: +61 3 6232 5547 | Fax: +61 3 6232 5000 >>> holger.neuhaus@csiro.au | www.csiro.au | >>> http://www.csiro.au/people/Holger.Neuhaus.html >>> >>> Address: GPO Box 1538, Hobart TAS 7001, Australia >>> >>> The Tasmanian ICT Centre is jointly funded by the Australian >>> Government >>> through the Intelligent Island Program and CSIRO. The Intelligent >>> Island >>> Program is administered by the Tasmanian Department of Economic >>> Development, >>> Tourism and the Arts. >>> >>> PLEASE NOTE >>> The information contained in this email may be confidential or >>> privileged. >>> Any unauthorised use or disclosure is prohibited. If you have >>> received this >>> email in error, please delete it immediately and notify the sender >>> by return >>> email. Thank you. To the extent permitted by law, CSIRO does not >>> represent, >>> warrant and/or guarantee that the integrity of this communication >>> has been >>> maintained or that the communication is free of errors, virus, >>> interception >>> or interference. >>> >>> Please consider the environment before printing this email. >>> >>> >>> >>> >> >> >> >> -- >> >> Luis Bermudez Ph.D. >> Coastal Research Technical Manager >> Southeastern Universities Research Association (SURA) >> bermudez@sura.org - Office: (202) 408-8211 >> 1201 New York Ave. NW Suite 430, Washington DC 20005 >> > >
Received on Tuesday, 20 April 2010 05:32:09 UTC