[Minutes-SSN] 2016-05-31

The minutes of last week's SSN call are at 
https://www.w3.org/2016/05/31-sdwssn-minutes with a text snapshot below.


    [1]W3C

       [1] http://www.w3.org/

           Spatial Data on the Web SSN Sub Group Teleconference

31 May 2016

    See also: [2]IRC log

       [2] http://www.w3.org/2016/05/31-sdwssn-irc

Attendees

    Present
           DanhLePhuoc, SimonCox, ahaller2, KJanowic, ByronCinNC,
           ByronCinNZ, robin, roba, kerry, ClausStadler, JRamsay

    Regrets
           Raul, Sefki, Scott, Phil

    Chair
           kerry

    Scribe
           Armin

Contents

      * [3]Topics
          1. [4]last meeting minutes
             https://www.w3.org/2016/05/17-sdwssn-minutes
          2. [5]Armin's Action-173 and Action-174
          3. [6]Correcting typos in SSN annotations Issue-60
          4. [7]Next task focus (suggest modularisation section 3).
      * [8]Summary of Action Items
      * [9]Summary of Resolutions
      __________________________________________________________

    <kerry> look at this!
    [10]https://www.w3.org/TR/2016/WD-vocab-ssn-20160531/

      [10] https://www.w3.org/TR/2016/WD-vocab-ssn-20160531/

    <kerry> scribe: Armin

    <kerry> scribenick: ahaller2

last meeting minutes [11]https://www.w3.org/2016/05/17-sdwssn-minutes

https://www.w3.org/2016/05/17-sdwssn-minutes

    +1

    <KJanowic> +1

    <SimonCox> +1

    <ClausStadler> +1

    <ByronCinNZ> +1

    <robin> +1

    RESOLUTION: approve last week's minutes

    <DanhLePhuoc> +1

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

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

    <roba> +1

    +1

    <KJanowic> congrats!

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

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

    <kerry> [14]http://www.w3.org/2016/05/31-sdwssn-irc

      [14] http://www.w3.org/2016/05/31-sdwssn-irc

Armin's Action-173 and Action-174

    [15]https://github.com/w3c/sdw/blob/armins-branch/ssn/images/mo
    dular_ontology.png

      [15] 
https://github.com/w3c/sdw/blob/armins-branch/ssn/images/modular_ontology.png

    <kerry> ahaller2: postsl link and mentiones actions commited to
    his branch

    <kerry> some examples around graph and new version of graph
    (diagram)

    <kerry> ahaller2: was thinking the core should be our sensor
    core in rdfs semantics like schema.org

    <kerry> ...maybe some informal local restrictions

    <kerry> ...Kerry and I spoke yesterday -- not sure what goes in
    core yet

    <KJanowic> See here for a proposal:
    [16]https://www.w3.org/2015/spatial/wiki/SSN_core_modules

      [16] https://www.w3.org/2015/spatial/wiki/SSN_core_modules

    <kerry> ... needs to be sensor, measurement calues, device
    class

    <kerry> ...then 2 outer core modules that introduces rich
    semantics from ssn

    <kerry> ...and imports sensing and sensing device

    <kerry> ..o&m modu,e woiuld import core

    <kerry> ..those 2 modules are independent. If they use a
    concept from the other module it will use the namespace of the
    other but does not import

    <kerry> ...in order to align we have this alignment thin layer
    on top

    <kerry> ... which would import both ssn and oml module

    <KJanowic> Does the O&M module include sampling?

    <kerry> ... no longer relies on dolce but this is on lhhs and
    imports ssn but not oml

    <kerry> ...core might have some annotation properties to point
    to other modules where they are defined

    <kerry> ... reusing terms

    <kerry> ...questions?

    <kerry> KJanowic: where would sensing a feature go?

    <kerry> ahaller2: i beleive in oml part but other people will
    think otherwise

    <kerry> KJanowic: i think we can tick this in -- email
    discussion coming

    <kerry> ... now old www work and core and oml

    <kerry> ... could we instead have an observation module and a
    sensor module instead/

    <SimonCox> I think Jano was asking about 'SamplingFeatures'
    which is part of O&M and om-lite

    <kerry> ahaller2: wanted to show ssn has all the rich semantics
    plus deployment etc

    <kerry> KJanowic: but should not show who invented it but theme
    based

    +1 for the naming, we need to change them!

    <KJanowic> @SimonCox: Yes, SamplingFeature will go into the
    observation module.

    <kerry> roba: a couple of thinks relating to KJanowic

    <kerry> ...regarding horizontal and vertical...

    <kerry> ,,,does this show both aspects combined?

    <SimonCox> WOuld be helpful to see SamplingFeatures explicitly
    in the diagram ...

    <kerry> roba: core menas citable concepts ned to be defined

    <kerry> ..need to clarify the role of each of thinks a bit
    better

    <KJanowic> Personally, I would have favoured a core, a sensor,
    an observation, and a deployment module and it is this
    deployment module where platforms, sampling, networks and so
    would go in.

    <kerry> ahaller2: good point .. the owl:import indicates
    vertical, others are horizontal but not well shown here

    <kerry> ...there are als osme examples to explain this in my
    doc

    <kerry> ... om is not the canonical

    <kerry> ...is this a naming clarification.

    <kerry> ...where would imports appear?

    <kerry> ...important that alignment modules are importing the 2
    independent

    <KJanowic> Agreed on the horizontal vs vertical layering issue.
    I have some examples with axioms here:
    [17]https://www.w3.org/2015/spatial/wiki/SSN_core_modules . I
    think these details will evolve when we work on the modules.
    this first draft from ahaller2 and kerry looks really good to
    me.

      [17] https://www.w3.org/2015/spatial/wiki/SSN_core_modules

    <SimonCox> Sampling features are closely linked to sensor
    deployment semantics - but can probably be decoupled from
    Observation module

    <kerry> ahaller2: dolce is only on outer layer of ssn, does not
    realte to o&m

    <kerry> ...simon's proposla is layered under prov

    <KJanowic> I still think DUL should be entirely removed from
    any official language in the standard.

    <kerry> roba: shouldn't dulce alignment import dulce

    <kerry> ... want some satellites around the outside

    <kerry> ahaller2: yes could show imports of external ontologies

    <kerry> DanhLePhuoc: coment on wiki page of ssn core module

    <kerry> ...talking about rdfs

    <kerry> worried about rdfs interpretation

    <kerry> ...if only using rdfs how doe we know whther to use
    rdfs reasoner

    <KJanowic> IMHO, Core should be as simple as schema.org. No
    OWL, no global domains and ranges.

    <kerry> ahaller2: was a bbit sloppy here ... prbably want rdfs
    1.1 ... doo we want owl:class

    <KJanowic> +1 to ahaller2

    <kerry> ...there just should be no rich semantics there, can
    use it as it is

    <DanhLePhuoc>
    [18]https://www.w3.org/TR/rdf11-mt/#rdfs-interpretations

      [18] https://www.w3.org/TR/rdf11-mt/#rdfs-interpretations

    <kerry> DanhLePhuoc: for me ehen you talk about rdfs i think
    rdfs interpretation

    <kerry> ...eg for a sparql enpoint with sparql entailment

    <kerry> e.g assuming implicit triples

    <DanhLePhuoc> [19]https://www.w3.org/TR/sparql11-entailment/

      [19] https://www.w3.org/TR/sparql11-entailment/

    kerry: not much reasoning in the core, class hierarchy
    ... would be nice if they are OWL classes
    ... you could use rdfs entailment, but you would be in the
    owl/rdfs intersection

    <KJanowic> I do not see the problem, what am I missing?

    <kerry> danh: see rdfs semantics 101, you can see the more
    expressive one covers the less expressive one so you can do
    rdfs and it will work with owl

    DanhLePhuoc: you define stuff in rdfs and OWL

    <kerry> ...if you have less powerful qurey processor you can do
    rdfs

    <kerry> ...on server you can do owl 2 but rdfs on gateway which
    still does some job for you

    <kerry> ...can then put data in server to get owl2 semantics

    <kerry> ...the good part we can put in best practice too --
    when you can use what kind of reasoning

    <kerry> ...WoT talks about only the xsd datatypes for
    interpretation

    <kerry> ...eg.g 5 is that same as 5.0

    <kerry> ..can still work for that

    s/eg/g 5/e.g. 5

    <kerry> SimonCox: suggestion that diagram misses undelying
    alignment with OGC model

    <kerry> ...something in the core that realtes to features e.g
    .sampling features

    <KJanowic> featureOfInterest would be in core

    <kerry> ...about assignment of properties to features

    <kerry> ...sampling features does this.

    <kerry> ...that side of observation model was not addressed in
    original ssn ans reamins invisible here

    <kerry> ... needed for linking over to best practices

    <kerry> ...want to suggest to look how midlle of diagram has
    asplit in 2

    <roba> Pushing to BP is good - but is Spatial data BP best
    place? Or only place in short term?

    <kerry> KJanowic: suggest we do not goo too far into what goes
    where

    <kerry> but are close to vertical and horizontal layering..

    <kerry> suggest vote on this

    +1 on voting

    <DanhLePhuoc> +1

    <KJanowic> +1

    <kerry> joshli: wants to see moreon how expressiveness works..
    can see central core and adding outside

    <KJanowic> My suggestion: the details will be worked out when
    we do the actual axioms. It looks like we finally all agree on
    the vertical and horizonal layering so maybe vote on this and
    move on?

    <roba> Also assignment feature properties is perhaps an
    entailment regime?

    <KJanowic> joshli: see example in the wiki

    <kerry> ... want to see how the vertical works but wants to see
    how

    <kerry> ...one other issue it puzzles me which is how ssn
    ontology does not cover netwrok realtionships

    <KJanowic> :observation \circ :featureOfInterest \sqsubseteq
    :observed // Assuming we have guarded domain and range
    restrictions in place.

    <kerry> e.g betewrrn platforms and sampling features and
    features of interest

    <kerry> kerry: ack KJanowic

    <kerry> ... see wiki link with propertychain example

    <SimonCox> link?

    <kerry> ... and agree about missing netowrk part

    <roba> +1

    <SimonCox> What is the motion?

    <KJanowic> the motion is to agree on the idea of vertical and
    horizontal layering (not yet on any details or count of
    modules)

    <SimonCox> +1

    +1

    <DanhLePhuoc> +1

    <roba> +1

    <ClausStadler> +1

    <KJanowic> +1

    <ByronCinNZ> +1

    <JRamsay> +1

    <kerry> +1

    <KJanowic> jay!

    yes

    <joshli> My understanding is that the horizontal modular
    relationships add new types of concepts, vertical
    m-relationships add more expressive predicates.

    <joshli> +1

    <KJanowic> IMHO, this is a very good first diagram that you did
    there and we can discuss and revisit the details as we go along

    RESOLUTION: agree on the idea of vertical and horizontal
    layering (not yet on any details or count of modules)

    <KJanowic> @joshli: yes

    <KJanowic> If Simon is willing to give me a hand, I would
    hammer out a first draft of CORE and how to add the sampling
    feature hook to that

Correcting typos in SSN annotations Issue-60

    kerry: we may need to include better explanations of the
    layering, referring to KJanowic wiki and the discussion we had
    in the meeting today
    ... bug with LODE that causes a lot of typos

    <SimonCox> @KJanowic must wait until July :-(

    kerry: happy to do it myself and freeze the document

    <KJanowic> NP, I can rework what is in the wikiand wait for
    your input.

    SimonCox: the ontology is still unstable, you may do a lot of
    extra work

    kerry: annotations will not change too much, as we probably
    won't take away much classes/properties
    ... annotations will appear mostly in rdfs:comment
    ... it is around foreign characters etc. that screwed up the
    first public draft
    ... not changing meaning, just fixing typos and characters that
    cause problems with LODE

    <KJanowic> +1

    <SimonCox> om-lite is heavily annotated!

    +1

    <roba> +1

    <SimonCox> +1

    <JRamsay> +1

    <DanhLePhuoc> +1

    <ByronCinNZ> +1

    <ClausStadler> +1

    <KJanowic> @ahaller2: can you upload an svg version of
    [20]https://github.com/w3c/sdw/blob/armins-branch/ssn/images/mo
    dular_ontology.png so that it can be edited?

      [20] 
https://github.com/w3c/sdw/blob/armins-branch/ssn/images/modular_ontology.png

    yes, KJanowic I can upload an svg version

    <KJanowic> thx

Next task focus (suggest modularisation section 3).

    kerry: what are our next steps?
    ... we could start working on what goes where
    ... proposals for what goes where and even naming

    agree that they should go in there, personally not in the core

    actuators are also important

    <KJanowic> not in the core but it should go somewhere and there
    is an existing axiomatization out there so it should be easy to
    do

    <KJanowic> +1, I get this question many times. We had to do our
    own version in the GeoLink project

    <joshli> The critical connection to all things IoT is
    FeatureOfInterest.

    <KJanowic> i agree with all this Kerry but IMHO we need to
    address those issues for which we have manpower. We have the
    sampling feature manpower right in the team. I agree that we
    need more on devices and so forth. All I am trying to get us
    agree on is that we need more on sampling.

    ahaller2: I can include samplingfeatures in the graph if that
    is important for the group

    kerry: my objections is that we have many other things and we
    have not voted on them

    roba: it is worthwhile to find this bridge between sensors and
    samplingfeatures
    ... in favour to include samplingfeatures, and it is a good use
    case for the modularisation
    ... it should be visible to the outside that this is something
    we consider

    kerry: ssn proposes sampling, but can not be used on its own

    <joshli> One approach would be to define the "interfaces" to
    proposed modules in advance of working on the modules, e.g. a
    stub representing a default sampling feature.

    <KJanowic> Agreed! work on adding sampling feature and more on
    devices at the same time.

    roba: we don't need to worry about details yet, but we should
    get the design right

    <KJanowic> see also here about the second part:
    [21]http://schema.geolink.org/patterns/core/physicalsample.html

      [21] http://schema.geolink.org/patterns/core/physicalsample.html

    <KJanowic> +1 to kerry's suggestion

    <roba> +1

    kerry: proposal to work next on samplingfeatures and small
    devices modularity

    <KJanowic> +1

    +1

    <SimonCox> I have to go.

    <DanhLePhuoc> +1

    kerry: please put proposals on the wiki

    <joshli> bye bye

    kerry: we may not have a meeting in two weeks time, because it
    may become a time meeting

    <KJanowic> Thanks everybody and bye bye

    kerry: we will have a meeting, but it will be about time

    <roba> cheers all

    bye

    <ClausStadler> bye

Summary of Action Items

Summary of Resolutions

     1. [22]approve last weeks minutes
     2. [23]agree on the idea of vertical and horizontal layering
        (not yet on any details or count of modules)

    [End of minutes]
      __________________________________________________________

Received on Monday, 6 June 2016 09:10:27 UTC