Semantic Sensor Network Incubator Group Teleconference -- 16 Feb 2010

<trackbot> Date: 16 February 2010

??P10 is me

<Holger> Laurent, that's "zakim, ??P10 is me" ;-)

<Payam> I can do this

<krzysztof_j> i will do no problem

<Holger> ScribeNick: laurent_oz

Kerry: W3C responded to our request for extension for 6 months positively - to be announced formally

Thank you to everybody which help for the draft report to help us to meet the extension

<krzysztof_j> worlds

<krzysztof_j> http://www.w3.org/2005/Incubator/ssn/wiki/images/5/5c/Sensor_ontology_alignment_to_dolce.pdf

Krzystof_j talking about how to align our ontology with Dolce

Discuss difference between observing the process and observation

3rd slide list concepts which needs to be clearly separated to avoid misuse of the SSN ontology

Slide 4 lists concepts which could be anchored to DOLCE as perdurants

Point to discuss: sensing as an event rather than a process

Slide 5 Feature used in two ways

Holger: is it easy or hard to align our ontology to Dolce

<michael> +q

<kerry> +q

Answer: it's relatively easy

Michael: two aspects, conceptualisation and data model - how we manage both aspects?

Kerry: it is better to let both aspects of an observation in the ontology

<krzysztof_j> +q

But the ontology should not be prescriptive in the format of the record of the observation

Kerry: the ontology should specify that the record of observation has a time

<krzysztof_j> ack to all you said

Krzysztof: challenge for sensors - they are the boundary of the real world and a world where we talk about models

<cory> +q

Cory: if we look at how properties are interpreted depending on how we use observation - location of a record is diffewrent from location of the observation itself

<krzysztof_j> ack

<krzysztof_j> +q

Kerry: need clarification on where to attach properties

<krzysztof_j> the location is also produced by an observation

<krzysztof_j> and hence lat/lon (or whatever) is also an observation record

<krzysztof_j> therefore we can have information about the location of a real world observation in its observation record

Kerry: "everything is an information" = overloading the observation concept

<krzysztof_j> but isn't this the case for OGC's sensor systems, the gps is just part of a huger sensor system

<Payam> +q

correction: everything is an observation

Payam: searching for the observation and searching for the sensors are the two main targets

for the scope of the ontology

<cory> +q

<michael> +q

Holger: we need to make clear the linkage between the sensor and observation

Cory: we also have provenance as a use case: provenance - do we point at where the record comes from (is stored) or go back to the sensor

Michael: looking at the last slide, we need to separate the abstract definition of the step and the record that at some time we've done these steps

<Payam> +q

<Payam> -q

Holger: what we have in the ontology is not the"real world event obsrvation" - question to K. : observation as an event is the real world observation and we need to put what's corresponding to the record (the produced data) would be in another place

<Payam> +q

<krzysztof_j> +q

<michael> observation has feature of interest, procedure etc - but they are restrictions on domains and range of properties, not observation

<michael> this was because we haven't made a decision as to if they were defining aspects of an observation or things it may have

<michael> yes

- Payam understands Michael's separation of concepts - 3 parts

Device itself

the process it does

The result

<krzysztof_j> +q

<Payam> The modelling could be done in layers

<Payam> starting from the device which does the observation

<Payam> then modelling the process and observation

<Payam> the accuracy and other quality of information parameters could be added to this model in different layers later

<kerry> I think K makes a good point: restrictions on the observation woud b cleaner than on the properties

Krzysztof's question was on how we use restrictions (someValuesFrom vs. domain/range) and the level of reasoning support we want to have

<michael> +q

Kerry also prefers the ontology design style where restriction are used locally

Michael: we have made those commitments

<krzysztof_j> +q

Michael: Observation is defined by having those restrictions

<krzysztof_j> ack

Kerry: can we have a vote on our choice to use local restrictions?

Rather than domain and range attached to properties

<krzysztof_j> +1

<michael> +q

Kerry adding an exception for the datatype properties where the range is expected to be defined

<krzysztof_j> maybe, but this is again about ontological commitments and i would always try to reduce them to a minimum

Kerry notes that at this stage we have not used datatype properties

but we may do so when we become more concrete

<Holger> vote: preferred usage of local restrictions over global restrictions

<Payam> +1

<krzysztof_j> +1

<kerry> +1

<cory> +1

<Manfred_DERI> +1

<michael> +1

<Holger> +1

<kerry> +q

<michael> -q

<krzysztof_j> (i have to leave in 2min, sorry (I would like to do the DOLCE alignment))

<krzysztof_j> this would be difficult

Laurent: making the point that it would be good to leave the user having the choice to import DOLCE or not

<kerry> +q

Krzysztof: there are cases where the decision to import would create a class of external statements which would become tricky to manage (e.g. a property declared at the top level as transitive)

<krzysztof_j> I will, thanks for all the comments!

Kerry thinks that if we carefully manage it, we should not have problems as long as we repeat those statements which are also in DOLCE

<krzysztof_j> cu

Kerry will present what she has on device next week

<Manfred_DERI> great!

<cory> bye

- DRAFT -

Semantic Sensor Network Incubator Group Teleconference

16 Feb 2010

Attendees

Contents

Summary of Action Items

Scribe.perl diagnostic output