Re: Sensor description

Hi Alexandra,

On Fri, Sep 11, 2015 at 2:07 PM Alexandra Kokkinaki <
alexandra.kokkinaki@gmail.com> wrote:

> Hi Markus and thanks for your prompt answer,
>
> ok that is clear enough to continue with my class building. What also
> comes to my mind, is the axioms per class.
> I have described my classes with axioms, but we are not going to use any
> reasoning yet, so I am not sure how useful my axioms are. Should I be
> describing the classes with axioms or not?
>

I guess this is more of an ontology engineering question. I would argue
that it is generally useful to describe your classes with axioms, if
nothing else at least state some subclass relationships in order to get a
class hierarchy. Even if you do not use any reasoning, the formal
descriptions can be useful in communication as well as to clarify own views
of the world.


> Every System[1] subclass e.g. SystemXXXX, will share common
> characteristics with its instances (different serial numbers) like
> MeasurementCapability[2], Operating Range[3] etc. My idea of modelling
> this, is to create a MeasurementCapability instance for System XXX and then
> connect it with the different serial number instances of Class SystemXXX,
> so that they share the same e.g. Measurement Capabilities. Does this sound
> sensible?
>

Two things:

1/ hasMeasurementCapability is a relation between Sensor and
MeasurementCapability. You might want to restrict the domain to the class
Sensor.

2/ More importantly, I would argue that serial numbers are not measurement
properties and thus you might not want to collect serial numbers as
measurement capabilities. Perhaps you could introduce the object property
hasSerialNumber as a sub property of SSN:hasValue and then connect the
sensing device to a DUL:Region which then connects to the serial number
value via DUL:hasRegionDataValue.

Cheers,
Markus

[1] http://www.w3.org/2005/Incubator/ssn/ssnx/ssn#hasMeasurementCapability


>
> Thanks again
>
> Alexandra
>
>
> [1]http://www.w3.org/2005/Incubator/ssn/ssnx/ssn#System
> [2]*http://www.w3.org/2005/Incubator/ssn/ssnx/ssn#MeasurementCapability
> <http://www.w3.org/2005/Incubator/ssn/ssnx/ssn#MeasurementCapability>*
> [3]
> *http://www.w3.org/2005/Incubator/ssn/ssnx/ssn#OperatingRange
> <http://www.w3.org/2005/Incubator/ssn/ssnx/ssn#OperatingRange>*
>
>
> On Fri, Sep 11, 2015 at 7:59 AM, Markus Stocker <markus.stocker@gmail.com>
> wrote:
>
>> Hi Alexandra,
>>
>> On Fri, Sep 11, 2015 at 12:35 AM Alexandra Kokkinaki <
>> alexandra.kokkinaki@gmail.com> wrote:
>>
>>> Hi,
>>>
>>> could you please help on that? I want to describe sensing devices
>>> consisting of sensors in RDF with the help of ssn ontology.
>>>
>>
>> Sounds like you have a System [1] with sensors (possibly sensing devices)
>> as sub systems [2].
>>
>>
>>> Each sensing device will have many serial numbers and each sensor will
>>> also have several serial numbers.
>>>
>>
>> Note that a sensor is "any entity that can follow a sensing method" [3]
>> and can include a lab technician who follows a protocol to measure a
>> property while a sensing device is an instrument. A sensing device is a
>> sensor, while a sensor may be a physical object other than a device.
>>
>> I think I would model serial numbers for systems, which will also work
>> for sensing devices.
>>
>>
>>> So I was thinking of creating a class for each type of sensing device
>>> under SensingDevice class  and a class for each type of sensor under Sensor
>>> class.
>>> Then publish this ontology with the new classes.
>>> Then create a new file only for the instances, which will import the new
>>> ontology.
>>>
>>
>> Looks like a sensible approach, especially if you want the first ontology
>> with your classes to be reusable.
>>
>> Cheers,
>> Markus
>>
>> [1] http://www.w3.org/2005/Incubator/ssn/ssnx/ssn#System
>> [2] http://www.w3.org/2005/Incubator/ssn/ssnx/ssn#hasSubSystem
>> [3] http://www.w3.org/2005/Incubator/ssn/ssnx/ssn#Sensor
>>
>>
>>> Is this the correct way to go?
>>>
>>> Thanks,
>>>
>>> Alexandra
>>>
>>
>