W3C home > Mailing lists > Public > public-xg-ssn@w3.org > July 2010

RE: operating and survival conditions

From: <P.Barnaghi@surrey.ac.uk>
Date: Wed, 14 Jul 2010 20:42:39 +0100
To: <Michael.Compton@csiro.au>
CC: <public-xg-ssn@w3.org>
Message-ID: <C253D9F4A2A12B489929917CEF6E553C51E2F22A1E@EXMB04CMS.surrey.ac.uk>
The Operational/survival model seems to better structured now. By having One supercalass you mean a class like OperationModel and then two sub-classes as SurvivalRange and OperatingRange?

I looked up some commercial sensor factsheets and tried to see how many of their attributes can be specified with the current operation model; it seems most of the common attributes could be defined under existing classes in the model. There were also attributes such as:

- electromagnetic interference (EMI) range, salt water and solvents effect, Chemical resistance (which I think will be under environmental survival range)

- Calibration cycle (which could be an attribute in Maintanance schedule)

and: Response time, Repeatability (which are probably a part of Quality of Information attributes?)


Regards,
Payam


________________________________________
From: Michael Compton [Michael.Compton@csiro.au]
Sent: 12 July 2010 07:00
To: Barnaghi P Dr (Electronic Eng)
Cc: public-xg-ssn@w3.org
Subject: Re: operating and survival conditions

Yes, they aren't linked.  I wasn't sure that there was anything to
say.  If we are to just have the same name for all the roles in that
diagram, then there doesn't seem to be any restriction to add that
links things.

I had a look at restructuring things a little.  I put up an extra
diagram and some text on the wiki page

http://www.w3.org/2005/Incubator/ssn/wiki/Operating_Model

We could put things together under a single superclass as we did in
the modelling of accuracy and then constrain the condition based on
that?

Michael




On 06/07/2010, at 20:30 , p.barnaghi@surrey.ac.uk wrote:

> Hi Michael,
>
> Regarding the first point, when I browsed the ontology some of
> classes related to operational and survival conditions are not
> mapped to any concept. The classes are defined but no link between
> the concepts and other parts of the ontology is defined.
>
> On the second point, I agree; we should stick to modelling sensors.
> What I described as a "Role" is related to a sensor node platform.
> We focus on sensors rather than sensor nodes or communication
> network or deployment platforms.
>
>
> - Payam
>
> -----Original Message-----
> From: Michael Compton [mailto:Michael.Compton@csiro.au]
> Sent: 05 July 2010 05:58
> To: Barnaghi P Dr (Electronic Eng)
> Cc: public-xg-ssn@w3.org
> Subject: Re: operating and survival conditions
>
> Firstly, sorry for the slow reply - I've been on holidays.
>
> I don't quite understand the first point.  Could you explain more
> fully.
>
> On the second point, it seems to me hard to define a line that clearly
> marks out "sensor only" (or predominantly sensor specific) from the
> myriad of other properties related the sensors and devices.  My
> feeling is that for the XG's ontology we should stick as closely as
> possible to things that are only relevant to sensors or things where a
> sensor ontology is a very likely place for it to be defined.
> Admittedly, such a thing is hard to get right and we have already
> considered non sensor only things, like the operating and survival
> conditions, which could apply to any device, but it's mostly/often
> sensors that get placed in those conditions, and these are things that
> are often the concern of sensors, so it seems reasonable to define it
> ourselves rather than rely on other ontologies.
>
> For things like acting as a router or storage hub, it seems to me that
> these are more broadly applicable network and concepts and, hence, it
> seems less appropriate to define them in a sensor ontology.  Does that
> make some sense?  Does anyone agree?  And of course are there other
> things we should include in this area?
>
> Michael
>
>
>
>
>
> On 25/06/2010, at 23:49 , p.barnaghi@surrey.ac.uk wrote:
>
>> Hi Michael,
>>
>> In SensorBasis_withSurvivalAndOperationalRange OWL file, it seems
>> some of the classes like StorageCapacity, OperatingRange have no
>> defined property.
>>
>> Also another question, in protocols like ZigBee there is a
>> possibility to define a sensor node as a Router in a wireless sensor
>> network, or a sensor node could be used as a storage hub for
>> replicating the data in some WSN designs. Do you think we should add
>> theses type of attributes to the model?
>>
>> Regards,
>> Payam
>>
>>
>> -----Original Message-----
>> From: public-xg-ssn-request@w3.org [mailto:public-xg-ssn-request@w3.org
>> ] On Behalf Of Michael.Compton@csiro.au
>> Sent: 22 June 2010 14:00
>> To: public-xg-ssn@w3.org
>> Subject: operating and survival conditions
>>
>> I've marked up Payam's suggestion for operating and survival
>> conditions into an OWL file (as an extension of the current version
>> of the ontology).  See http://www.w3.org/2005/Incubator/ssn/wiki/Operating_Model
>>
>> I hope I've interpreted it properly.  All comments welcome - Payam,
>> if you see anything amiss let me know.
>>
>> On the same page is an example that encodes the operating and
>> survival conditions for a sensor.
>>
>> Both files are attached here.
>>
>> Michael
>
Received on Wednesday, 14 July 2010 19:43:11 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:03:16 UTC