Re: [Minutes-SSN] 2016-04-19

Hi,

Apologises for spamming your conversation and please ignore it if it is irrelevant. I developed an ontology, which is called Stream Annotation Ontology (SAO), to overcome the representation issues of observations including their temporal concepts, such as segment, point. It has been built on top of PROV-O, SSN, and TimeLine Ontology. TimeLine ontology enables SAO to support temporal relations (Allen’s temporal relations). Although it sounds very simple, it is very useful to represent any data analysis output in RDF form. The idea when I was building the ontology was data could be in any format, audio, video, sensory data. Therefore, it tackles this issue by assuming that data can be one point or an array or data. I didn’t use any RDF bags for representation. It simply uses string format to represent outputs; and allows to describe the row and column size of the given data set, so that anyone can quickly reshape and use data as a matrix. SAO is also being used in IoT-Lite Ontology that was previously mentioned by Payam and Kerry. Please find below the web page and the published article (IEEE iThings 2014) related to SAO Ontology.
The web site of SAO Ontology:
http://iot.ee.surrey.ac.uk/citypulse/ontologies/sao/sao
The article that explains SAO Ontology:
A Knowledge-based Approach for Real-Time IoT Data Stream Annotation and Processing
http://ieeexplore.ieee.org/xpl/articleDetails.jsp?reload=true&arnumber=7059664
For those who don’t have access to IEEE, the article is given below:
https://docs.google.com/viewer?a=v&pid=sites&srcid=ZGVmYXVsdGRvbWFpbnxzZWZraWtvbG96YWxpfGd4OjFiNTYwZDU3ODUwNzYxNGU

In order to have an idea how it works, please find below the SAOPY library that I have developed to help people avoid making mistakes. It involves SAO ontology as well.
http://iot.ee.surrey.ac.uk/citypulse/ontologies/sao/saopy.html

I would like to apologise for not being able to participate to the SSN meetings, however, the meetings are being held at 10PM BST. I will be very happy to contribute if a task is given.

Cheers,

Sefki Kolozali
Research Fellow
Institute for Communication Systems (ICS), home of the 5G Innovation Centre
University of Surrey
Guildford, Surrey, GU2 7XH, United Kingdom
Tel: +44 (0)1483 689490

E-mail: s.kolozali@s<mailto:s.kolozali@qmul.ac.uk>urrey.ac.uk<http://urrey.ac.uk>
http://www.surrey.ac.uk/ics/<http://www.surrey.ac.uk/ccsr/>






On 25 Apr 2016, at 01:18, Simon.Cox@csiro.au<mailto:Simon.Cox@csiro.au> wrote:

My apologies for not being able to attend the meeting - I was running a workshop in Canberra.

Jano makes an important point here:

<KJanowicz> keep in mind that there are many orders of magnitude more observations than sensors

but not quite sure what the implications of that for modularization are.

The O&M Observations model was conceived as a consumer-oriented viewpoint, to complement the SensorML producer-oriented viewpoint. (Hence SOS 2.0, which is for getting observation data, uses the O&M model and terminology in its query.)
This played out as follows:
(i) O&M promoted the properties that we thought were required for data discovery to the top (i.e. observed-property, feature-of-interest, procedure used (i.e. sensor)). But no model was provided for any of these, so matching was 'by identifier' (e.g. 'show me observations about propertyA of featureB') or using structures that were delegated to a user-community;
(ii) SensorML provides a highly flexible XML format. Easy on providers. Very hard on consumers who have to be prepared to handle a huge variety of incoming data structures that are all conformant to SensorML.

My hunch is that detailed discovery scenarios require detailed descriptions of observable properties, which support reasoning. These might be provided as a side-effect of detailed sensor descriptions, but possibly worth thinking about them in their own right. And also spatial queries, which might involved reasoning if words rather than numbers are used ;-)

Simon J D Cox
Research Scientist
Land and Water
CSIRO
E simon.cox@csiro.au<mailto:simon.cox@csiro.au> T +61 3 9545 2365 M +61 403 302 672
  Physical: Reception Central, Bayview Avenue, Clayton, Vic 3168
  Deliveries: Gate 3, Normanby Road, Clayton, Vic 3168
  Postal: Private Bag 10, Clayton South, Vic 3169
people.csiro.au/C/S/Simon-Cox<http://people.csiro.au/C/S/Simon-Cox>
orcid.org/0000-0002-3884-3420
researchgate.net/profile/Simon_Cox3

________________________________________
From: Phil Archer <phila@w3.org>
Sent: Thursday, 21 April 2016 1:14 AM
To: SDW WG Public List
Subject: [Minutes-SSN] 2016-04-19

The minutes of this week's SSN call are at
https://www.w3.org/2016/04/19-sdwssn-minutes and in text form below.


  Spatial Data on the Web Working Group, SSN Sub Group Teleconference

19 Apr 2016

   See also: [2]IRC log

      [2] http://www.w3.org/2016/04/19--irc

Attendees

   Present
          RaulGarciaCastro, DanhLePhuoc, kerry, kJanowicz, robin,
          Claus, Stadler, ClausStadler, ahaller2, JRamsay

   Regrets
          phila

   Chair
          kerry

   Scribe
          DanhLePhuoc

Contents

     * [3]Topics
         1. [4]Modularity: discuss Armin's proposal
         2. [5]"Sensor" related to DUL: not a physical object,
            should be an Object?
         3. [6]Sensor" annotation: clarify relation to O&M Concept
     * [7]Summary of Action Items
     * [8]Summary of Resolutions
     __________________________________________________________

   <KJanowicz> has the meeting started?

   <JRamsay> sorry, whats the webex password again?

   hi Kerry, where can I the meeting Id and password?

   <robin> Meeting ID is 647 066 501

   <robin> I find from this
   [9]https://www.w3.org/2015/spatial/wiki/Meetings:SSN-Telecon201
   60419

      [9] https://www.w3.org/2015/spatial/wiki/Meetings:SSN-Telecon20160419

   <RaulGarciaCastro> it is

   <robin> But I don't know the password

   <robin> Thank you

   <KJanowicz> kerry, you are breaking awar, maybe turning your
   head away from the mic

   <KJanowicz> i can do it

   <kerry> scribe: DanhLePhuoc

   <kerry> scribeNick: DanhLePhuoc

   <kerry> patent call:
   [10]https://www.w3.org/2015/spatial/wiki/Patent_Call

     [10] https://www.w3.org/2015/spatial/wiki/Patent_Call

   is it this one? [11]https://www.w3.org/2016/04/13-sdw-minutes

     [11] https://www.w3.org/2016/04/13-sdw-minutes

   <kerry> [12]http://www.w3.org/2016/04/05-sdwssn-minutes

     [12] http://www.w3.org/2016/04/05-sdwssn-minutes

   <kerry> aprove minutes:
   [13]http://www.w3.org/2016/04/05-sdwssn-minutes

     [13] http://www.w3.org/2016/04/05-sdwssn-minutes

   <kerry> +1

   <RaulGarciaCastro> +1

   +1

   <robin> +1

   minutes approved

Modularity: discuss Armin's proposal

   First item for meeting is : Modularisation

   [14]http://w3c.github.io/sdw/ssn/#Modularisation

     [14] http://w3c.github.io/sdw/ssn/#Modularisation

   Armin: the current version proposes two ways of modularisation:
   Vertical Segmentation and Horizontal Segmantation

   The main idea ofr Vertical segmentation is to use a subset of
   modules/concepts without having uses another part

   In the other hand, it's a bit tricky in the Horizontal
   Segmentation

   KJanowicz: is possible to get rid of DUL completely?

   kerry: it is worth to use DOCLE as it has its own community and
   we might need similar one to fill in the missing concepts

   KJanowicz: be aware of maintenance problem of DOCLE
   ... I was among the one that proposed to use DOCLE for SSN
   ... I'm fine with keep it but I would like to highlight the
   issues

   <RaulGarciaCastro> +1 to having it out of the recommendation

   +1 for leaving DOCLE out this recommendatin

   <ahaller2> agnostic about it, but keeping it out of the
   standard may be a good solution

   <KJanowicz> +1

   RESOLUTION: that DUL alignment becomes a note or some other
   product outside the recommendation

   <KJanowicz> +1

   +1

   KJanowicz: would it make sense to have different level of
   complexity?

   <KJanowicz> so, simple observation model module, sensor module,
   observation module, deployment module, and a sampling module

   ahaller2: I don't see any use case to have to many separated
   modules

   KJanowicz: I have a project only have observations, but there
   are some other UCs can combine some subsets of deployment,
   sensor module....

   ahaller2: the core sensor module would be enough concepts and
   properties to cover most of the need
   ... the core sensor module would have enough concepts and
   properties to cover most of the need
   ... I meant sensing device core

   <KJanowicz> rename sensing deviced core into sensor and
   observation core

   ahaller2: a minimal subset of sensing device at very abstract
   level but cover most of generic and simple cases

   <KJanowicz> keep in mind that there are many orders of
   magnitude more observations than sensors

   kerry: the ways of current SSN used vary a lot in terms of
   grouping the concepts/modules, like IoT-Lite

   ahaller2: the core sensing device is proposed is similar to
   IoT-lite, but it's is in more light-weight

   <Zakim> RaulGarciaCastro, you wanted to talk about vertical and
   horizontal segmentation

   ahaller2: if we pulled out too many modules, it's really hard
   to know what it is a module

   <KJanowicz> I would still propose to have something like a
   minimal sensor-observation model

   RaulGarciaCastro: introducing more modules might be more
   confusing

   <kerry> +q

   <KJanowicz> I agree with ahaller2 heree

   ahaller2: in the end: what is our core? defining sensor as the
   central concept or sensor-obversion is the core here

   KJanowicz: SSN was the first effort that put sensor and
   observation together to make them usable in many cases over the
   year

   <KJanowicz> +1 for the alignment based version

   <KJanowicz> q_

   kerry: the concepts and properties can be added gradually via
   alignments to make them more flexible

   <KJanowicz> great idea!

   <KJanowicz> yes, lets do this!

   ahaller2: each of us will group the classes in modules to bring
   to the next meetings to discuss

   <ahaller2> +1

   +1

   <RaulGarciaCastro> +1

   <KJanowicz> +1

   <ClausStadler> +1

   <kerry> ach DanhLePhuoc

"Sensor" related to DUL: not a physical object, should be an Object?

   kerry: we can discuss about we can discuss logic profiles.e.g,
   RDFS, OWL ... in later stages

   in current "Sensor" is very general concept

   <KJanowicz> this will cause problems

   <ahaller2> +1 on moving sensor up in the hierarchy

   kerry: I put the alignment by : Sensor is subclass of
   dul:Object

   <KJanowicz> yes, I will

   <KJanowicz> I also agree that sensors should include humans and
   simulations

   KJanowicz: will need to look closely to this issue

   <KJanowicz> I think computation in DUL will be in the
   'abstract' part of DUL. I will check

Sensor" annotation: clarify relation to O&M Concept

   <ahaller2> +1 reasonable

   +1

   <KJanowicz> +1

   RESOLUTION: sensor annotation adjusted as discussed

   <ahaller2> we don't have a resolution yet, though

   kerry: we will bring up the issues to the big meeting

   ahaller2: it might be a bit early to bring to the big meeting
   due to a lot of uncertainty a.t.m

   <KJanowicz> thanks, bye bye

   <RaulGarciaCastro> Bye!

   bye!

   <kerry> rrsagent: draft minites

   <robin> Thanks, bye

Summary of Action Items

Summary of Resolutions

    1. [15]that DUL alignment becomes a note or some other product
       outside the recommendation
    2. [16]sensor annotation adjusted as discussed

   [End of minutes]
     __________________________________________________________


    Minutes formatted by David Booth's [17]scribe.perl version
    1.144 ([18]CVS log)
    $Date: 2016/04/20 14:39:19 $
     __________________________________________________________

     [17] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
     [18] http://dev.w3.org/cvsweb/2002/scribe/