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 Monday, 12 July 2010 06:01:02 UTC