[Minutes-SSN] 2016-07-12

The minutes of this week's SSN meeting are at 
https://www.w3.org/2016/07/12-sdwssn-minutes with a snapshot below.


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

           Spatial Data on the Web SSN Sub Group Teleconference

12 Jul 2016

    See also: [2]IRC log

       [2] http://www.w3.org/2016/07/12-sdwssn-irc


           kerry, KJanowic, SimonCox, DanhLePhuoc, roba,
           RaulGarciaCastro, scottsimmons




      * [3]Topics
          1. [4]patent call
          2. [5]SSN Requirements from UCR
          3. [6]ISSUE-20 Reference external vocabularies
          4. [7]ISSUE-24 clarification of lightweight APIs
          5. [8]Suggested changes to ontology editing
          6. [9]SOSA/SANDA?
      * [10]Summary of Action Items
      * [11]Summary of Resolutions

    I can scribe


    <kerry> scribe: KJanowic

    <kerry> scribenick: KJanowic

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

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

    kerry: Discussion of how much change we can/should do compared
    to OWL:Time
    ... Dont delete but deprecate

    Simon: we are fine as long as we use a new namespace

    kerry: Agreed, but this is also about respecting the current
    user base

    <ahaller2> s/dont/don't

    Try to avoid removing parts of the ontology (axioms)

    ahaller2: we use a new namespace so we should be fine. The core
    will be significantly different but one of the other layers
    would be very similar to the existing SSN.

    Kerry: fair enough. We have more flexibility than OWL:Time

    <ahaller2> +1 for not adding deprecated classes in the core


    Sure, I know this

    kerry: Agreed but we need to take it back to the group and be
    respectful of existing users

    Simon: I am pretty sure that this only applies for a previously
    published namespace.
    ... protecting users is done via not making changes to the
    existing namespace.

    kerry: lets wait for Phil and move on in the agenda

SSN Requirements from UCR

    kerry: This is purely a reminder to have a look at UCR and that
    we are all happy with the current content.

ISSUE-20 Reference external vocabularies

    <kerry> issue-20?

    <trackbot> issue-20 -- Reference external vocabularies -- open

    <trackbot> [13]http://www.w3.org/2015/spatial/track/issues/20

      [13] http://www.w3.org/2015/spatial/track/issues/20

    <kerry> ?

    kjanowic: isn't this about nomenclature? If so, we should deal
    with it
    ... so this is also about typecasting between class and entity
    based classifications, right?

    Rob: We also need to look into units of measure

    [My daughter just woke up, can somebody please scribe for

    <kerry> roba: no the issue does not need to stay as it will be
    picked up by broader best practice environment although it is

    <kerry> ....whether uom should be part of ssn for example?

    <roba> i'll scribe

    <kerry> ACTION: frans to close issue-20 please [recorded in

      [14] http://www.w3.org/2016/07/12-sdwssn-minutes.html#action01]

    <trackbot> Created ACTION-184 - Close issue-20 please [on Frans
    Knibbe - due 2016-07-19].

    <roba> ...pointed out that its a general BP - but a Use Case
    and consideration of UoM as a challenge is SSN space

ISSUE-24 clarification of lightweight APIs requirement

    <roba> ...kerry - consensus is then the close issue

    <kerry> issue-24?

    <trackbot> issue-24 -- clarification of lightweight APIs
    requirement -- open

    <trackbot> [15]http://www.w3.org/2015/spatial/track/issues/24

      [15] http://www.w3.org/2015/spatial/track/issues/24

    <roba> raul - infrastructure requirement not onotology req.

    <roba> armin - agree its infrastructure but points out that
    lightweight core will support lightweigt APIs

    <roba> kerry - UCR closing - need concrete proposal

    [I am back, sorry]

    <ahaller2> ahaller-

    <roba> Danh - more general problem?

    <roba> Kerry - change to an example

    Danh: Rephrase this requirement to the lightweight profile of
    the ontology wrt IoT.

    <RaulGarciaCastro> +1

    <roba> roba: req reads like it is intended to ensure SSN is
    relevant to the IoT space - but we would need the IoT req

    <DanhLePhuoc> +1

    <roba> +1

    <ahaller2> +1

    <kerry> +1

    Proposal: Ask Franz to rephrase


    <kerry> ACTION: frans to rephrase issue-24 requirement to
    something like "develop lightweight profile of the ontology for
    IoT" [recorded in

      [16] http://www.w3.org/2016/07/12-sdwssn-minutes.html#action02]

    <trackbot> Created ACTION-185 - Rephrase issue-24 requirement
    to something like "develop lightweight profile of the ontology
    for iot" [on Frans Knibbe - due 2016-07-19].

    Sounds good to me

    whether this is about profiles or not is another story that we
    can discuss at a later time

    Simom: Develop an example how the ontology can be used. The
    SOSA Core is not a profile.

    Kerry: Show how the ontology can be used for lightweight IOT

    <ahaller2> maybe "require a lightweight way to exchange data
    according to the SSN ontology"

    see above

    <ahaller2> "in the IoT context"

    final version: Show how the SSN ontology can be applied in the
    context of lightweight IoT needs



    <ahaller2> APIs are always about exchange

    <ahaller2> +1

    <roba> +1

    <DanhLePhuoc> +1

    <RaulGarciaCastro> +1

    <kerry> ACTION: frans to fix issue-24 by replacing requirment
    to "Show how the SSN ontology can be applied in the context of
    lightweight IoT needs" [recorded in

      [17] http://www.w3.org/2016/07/12-sdwssn-minutes.html#action03]

    <trackbot> Created ACTION-186 - Fix issue-24 by replacing
    requirment to "show how the ssn ontology can be applied in the
    context of lightweight iot needs" [on Frans Knibbe - due

Suggested changes to ontology editing process/tooling

    Ahaller2: We moved the ontology away from Webprotege for may
    reasons, one of them being issues with the namespace. This
    makes it pretty unusable for our work. Proposal was to use
    ... Most people will edit the file directly.

    We can usue whatever we want as long as we are carful with our
    github pull requests and the way we handle the raw file


    <SimonCox> I find TopBraid generates a very consistent
    serialization. It just isn't the same as Protege ...


      [18] https://github.com/w3c/sdw/blob/kjanowicz-ssn/ssn/rdf/sosa.ttl

    <roba> KJanowic: - didnt get that sorry..

    <roba> Kerry: asks for summary

    Ahaller2: What we did was taking kjanowic work, add the
    actuator class and then change the name and so forth.

    ahaller starting the discussion on process and procedure

    <SimonCox> Armin + Simon worked on SANDA -


    <SimonCox> Simon and Jano worked on

      [20] https://www.w3.org/2015/spatial/wiki/SOSA_Ontology

    <SimonCox> Re Procedure - should be " ... responsible for
    generating an observation result or another change in the

    <ahaller2> +1 on distinguishing the instruments and the
    procedure. This was definitely my intention in the first
    proposal of the core

    <RaulGarciaCastro> +1

    ahaller2, great. But if you look at samplingprocedure and
    procedure now, only sampling procedure is about a procedure.

    simon: agreed, there is some confusion that we need to clean up

    <ahaller2> KJanowic: That was a problem of wrong documentation
    of the class.

    <ahaller2> KJanowic: Webprotege was playing up with us

    <ahaller2> KJanowic: reintroducing rdf:comments for whatever

    aheller2: Sure, I just wanted to point this out

    same for Results being only created by Sensors (I already
    changed this)

    Very important issue

    <ahaller2> +1 to KJanowic, the procedure is measuring the
    temperature of soil or air, depending on how you use the

    <roba> +1 to KJanowic

    <RaulGarciaCastro> +1

    <SimonCox> ObservingProcedure is subclass of Procedure and
    superclass of Sensor?

    <ahaller2> SimonCox: we called it Sensing, didn't we

    <SimonCox> Procedure is also superclass of ActuatingProcedure
    and SamplingProcedure

    <SimonCox> ??

    Simon: IMHO, the procedure is like to cookbook recipe. It is
    not a superclass of sensor.

    <SimonCox> Yes - Sensing/Actuating/Sampling better names

    <ahaller2> Then yes

    <SimonCox> Agree - is recipe, not device

    <SimonCox> Uses a device

    It is a bridge to workflows

    <SimonCox> Agree

    Kerry: sorry, yes I will

    yes, so if the procedure is a sequence of actions (like in a
    receipt) and not a device, than we should change the

    Rob: There needs to be a method to identify a procedure as well
    as to describe it

    <ahaller2> +1 to change the description. I think we all are on
    the same page


    We are also talking about the subtle differences between
    sensing and a procedure

    Rob: Just needs to be clear to the usage

    <kerry> krz: there are instruments, that might be a specific
    sensor that

    <kerry> ...carries an observation, a sensing is always tking

    <kerry> ...but an observation procedure is more of a'to take a
    measurement do these steps"

    <kerry> ...this is a procedure that makes sure [missed]

    <kerry> ...want to be as inclusive as we can e,g instruments
    and human sensors

    <ahaller2> SensingDevice is an Instrument

    <ahaller2> We need to be careful with the Sensor class, this is
    why we renamed it to Sensing, because Sensor sounds like a

    <kerry> .... want to distinguish describing a procedure from

    <roba> works for me - needs to be front anb centre of

    If this is okay with everybody, I can do the change in SOSA
    (this is all just about the comment, there is no axiom anyway

    <kerry> armin: need to be careful with sensor class which
    sounds like an instrument

    ahaller2: lets be careful with sensor class as it sounds like
    an instrument. sensing is the super class
    ... we should use sensing

    <kerry> ... but sensing is a superclass..., sensor could be
    confused with sensing device

    Danh: Completely different question: What about the way we are
    coding, i.e., RDF versus OWL.

    <ahaller2> Sensing would not be the Instrument

    <roba> agree

    <kerry> krz: sensing implies an action, we need to discuss how
    to call this on the email list -- the procedure and the thing
    that executes it is doffernt

    <ahaller2> SensingDevice is the Instrument

    <ahaller2> Human could be the Instrument

    In short: there is the procedure and the XYZ that carries out
    this procedure to generate a valid observation

    <ahaller2> yes

    The question is how we call XYZ so that it includes sensors,
    simulations, humans,...

    kerry closing the meeting

    <ahaller2> XYZ could be Sensor, but not sure about the name

    <SimonCox> ObservingProcedure?

    <SimonCox> EstimatingProcedure?

Summary of Action Items

    [NEW] ACTION: frans to close issue-20 please [recorded in
    [NEW] ACTION: frans to fix issue-24 by replacing requirment to
    "Show how the SSN ontology can be applied in the context of
    lightweight IoT needs" [recorded in
    [NEW] ACTION: frans to rephrase issue-24 requirement to
    something like "develop lightweight profile of the ontology for
    IoT" [recorded in

      [21] http://www.w3.org/2016/07/12-sdwssn-minutes.html#action01
      [22] http://www.w3.org/2016/07/12-sdwssn-minutes.html#action03
      [23] http://www.w3.org/2016/07/12-sdwssn-minutes.html#action02

Summary of Resolutions

    [End of minutes]

Received on Wednesday, 13 July 2016 15:09:26 UTC