W3C home > Mailing lists > Public > public-sdw-wg@w3.org > April 2017

[Minutes SSN] 2017-04-11 call

From: Francois Daoust <fd@w3.org>
Date: Wed, 12 Apr 2017 17:00:57 +0200
To: <public-sdw-wg@w3.org>
Message-ID: <044101d2b39d$9747ace0$c5d706a0$@w3.org>
Hello,

The minutes of yesterday's SSN call are available at:

https://www.w3.org/2017/04/11-sdwssn-minutes.html

... and pasted as raw text below. Good progress during the call. Please note that there will be another SSN call today, 12 April 2017 at 20:00 UTC to go through remaining issues.
 
Thanks,
Francois.

-----
Spatial Data on the Web SSN Group Teleconference
11 April 2017

   [2]Agenda [3]IRC log

      [2] https://www.w3.org/2015/spatial/wiki/Meetings:SSN-Telecon20170411
      [3] http://www.w3.org/2017/04/11-sdwssn-irc

Attendees

   Present
          ahaller2, ChrisLittle, ClausStadler, DanhLePhuoc,
          Francois, KJanowic, mlefranc, ScottSimmons, SimonCox

   Regrets
          Kerry, Raul, Sefki

   Chair
          Armin

   Scribe
          SimonCox, tidoust

Contents

     * [4]Meeting Minutes
         1. [5]Approve last week’s minutes https://www.w3.org/
            2017/03/28-sdwssn-minutes
         2. [6]patent call https://www.w3.org/2015/spatial/wiki/
            Patent_Call
         3. [7]Progress on ACTION-296 to address role of device
            class as of ISSUE-153 and propose a solution
         4. [8]Progress on ACTION-302 for options in regards to
            Sensing class in SSN new
         5. [9]Deprecate ssn:SensorDataSheet as suggested in
            ISSUE-121
         6. [10]sensor datasheet
         7. [11]Progress on ACTION-304 to investigate the need of
            a complex result time property in SSN new
         8. [12]Progress on ACTION-273 for François Daoust to
            check whether we can/should add licence statement to
            /ns docs and, if so, which one
         9. [13]Decision on whether Platforms may be attached to
            Platforms ISSUE-154
     * [14]Summary of Action Items
     * [15]Summary of Resolutions

Meeting Minutes

Approve last week’s minutes [16]https://www.w3.org/2017/03/
28-sdwssn-minutes

     [16] https://www.w3.org/2017/03/28-sdwssn-minutes

   <KJanowic> +1

   <ahaller2> +1

   +1

   <ScottSimmons> +0

   <mlefranc> +1

   <DanhLePhuoc> +1

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

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

   [Armin goes through the patent call]

Progress on ACTION-296 to address role of device class as of
ISSUE-153 and propose a solution

   ACTION-296?

   <trackbot> ACTION-296 -- Krzysztof Janowicz to Look into
   [18]https://www.w3.org/2015/spatial/track/issues/153 and
   propose a solution -- due 2017-04-11 -- OPEN

     [18] https://www.w3.org/2015/spatial/track/issues/153

   <trackbot> [19]http://www.w3.org/2015/spatial/track/actions/296

     [19] http://www.w3.org/2015/spatial/track/actions/296

   <KJanowic> [20]https://www.w3.org/2015/spatial/wiki/
   Link_between_platform_and_device

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

   KJanowic: Question about what to do with the class Device,
   Sensing.
   … There was a sentiment that we could get rid of Device
   … In SOSA, we have Sampler, Actuator, so we don't need those
   except if we want them to be physical which we agreed we don't
   want.
   … We should drop SensingDevice.
   … The second part is the Device class itself, declared to be
   physical.
   … The notion of Platform has moved to Sensor, so you could
   argue that we don't need Device anymore.
   … Idea is to keep Platform as a superclass of Device.
   … 3 steps:
   … 1/ Drop SensingDevice
   … [missed other 2 steps]

   mlefranc: I fully agree. One question is what happens with some
   people that used oldSSN and made some difference between Device
   and System.
   … Maybe these people will react during the wide review of the
   specification.

   <KJanowic> no, not exactly

   mlefranc: Device and System would be somehow merged, right?

   <KJanowic> most of device are now platform

   KJanowic: Most of Device is now fully captured by Platform.
   … The rest can be captured by System, or you can use Device,
   it's just deprecated.
   … You can also add your own subclasses.

   <SimonCox> are we just simplifying
   sensor/device/platform/system arrangement here? Too many
   special words ... ?

   KJanowic: I don't think we're missing something, but maybe
   somebody will bring something forward that we haven't
   considered.

   <mlefranc> ok, totally agree

   <KJanowic> subclass

   ahaller2: SensingDevice, if we deprecate it, should we make it
   a subclass of Platform?

   <KJanowic> platforms are not necessarily physical.

   <KJanowic> yes, simplifying sensor/device/platform/system and
   making sure we fully include actuators and samplers

   SimonCox: Trying to understand what is going on here. There's
   always different pieces of physical arrangements: Sensor,
   Device, Platform. Here, the idea is to get rid of one of those.
   … Is it the case?

   ahaller2: This is all around SSN new. We will still have a
   SensingDevice, although it would be deprecated because the
   Platform class pretty much covers it entirely.
   … SensingDevice would just be a subclass of the Platform class.

   SimonCox: OK, the word SensingDevice has always confused me. If
   that can help simplify this, that's great.

   ahaller2: I was also confused by the difference between
   SensingDevice and Sensor initially, indeed.

   KJanowic: It's also to make sure that we are consistent.
   Coverage of sampling, sensing, actuation. Either we blow up
   more terms in SSN, or we reduce terms a bit.
   … We are just cleaning up here.

   SimonCox: Then I probably need to review the O&M alignment with
   the work we've done on Sampling.

   <KJanowic> no, they are in subclass relation

   mlefranc: I'm very happy that the old SSN is simplified with
   fewer classes. Is it true that SensingDevice and Sensor are now
   conflated in the class Sensor, and Device and SensingDevice are
   conflated in Platform?

   ahaller2: Yes.

   KJanowic: Sensor and Sensing devices are now very close, but
   there are no non physical sensing devices. You cannot have a
   smartphone simulation.

   <ahaller2> PROPOSED: Deprecate SensingDevice class in the
   alignment to SSN new and make it a subclass of sosa:Platform

   <KJanowic> +1

   <ahaller2> +1

   <ClausStadler> +1

   <mlefranc> 0

   <KJanowic> could be both, it is an even split :-)

   mlefranc: I don't really understand why it's a subclass of
   Platform and not a subclass of Sensor. It might be both,
   actually.

   <SimonCox> The word 'Device' is overloaded in 2017 :-(

   <DanhLePhuoc> 0

   <mlefranc> ok

   KJanowic: The device is what matters in the end, I think, but
   it's really a tiny decision.

   ahaller2: It does not really hurt if we add another subclass
   relationship.

   SimonCox: There's a lot of different constellations of devices,
   sensors, platforms, and the degree of details that gets exposed
   to consumers is the prerogative of the data provider.

   <KJanowic> Just FYI : "SensingDevice A sensing device is a
   device that implements sensing."

   SimonCox: Perhaps each of us has an incomplete set of
   relationships in our mind. In order to support the general
   case, we need to back off a little. My interpretation is that
   the proposal here is achieving that.
   … It may be that some of the words that we end up using in the
   ontology are not the ones we would use naturally.

   KJanowic: What I like to do in this case, is to look at axioms
   and syntactic, and forget about the terms themselves.
   … [going through axiomatization links]
   … From a purely logical perspective, we could deprecate the
   term without even introducing a subclass relationship.

   <DanhLePhuoc> [21]https://www.w3.org/TR/generic-sensor/

     [21] https://www.w3.org/TR/generic-sensor/

   KJanowic: We have it through transitivity already.

   <ahaller2> PROPOSED: Deprecate SensingDevice class in the
   alignment to SSN new

   ahaller2: OK, then I need to rephrase the proposal

   <mlefranc> +1

   <ahaller2> +1

   <mlefranc> agreed

   <DanhLePhuoc> 0

   <SimonCox> +1

   <ClausStadler> +1

   <KJanowic> +1

   DanhLePhuoc: Generic sensor API has a definition of Sensor and
   Device.
   … Sensor is attached to Device.

   <KJanowic> Yes, we have exactly the same ~idea using the
   relation of sensor to platform

   DanhLePhuoc: Some projects have been using SensingDevice to
   represent that

   <KJanowic> the attachment is now modeled by the relation of
   sensors to platforms

   ahaller2: I had a long discussion with Tobie at last TPAC. It
   would be hard to align SSN with the Generic Sensor API, but it
   would be useful to provide an alignment with the Generic Sensor
   API.
   … I don't know if we can add it on our way to REC, that would
   be useful, but I don't think we should duplicate the terms,
   because of the way they use it in the API.
   … They use Device the same way as we use Platform.

   Resolved: Deprecate SensingDevice class in the alignment to SSN
   new

   KJanowic: The attachment thing is now with Platform, so it's
   still there.
   … For Platform, you're interested in the geometry of things.

   <ahaller2> PROPOSED: Deprecate Device class in the alignment to
   SSN new

   <KJanowic> +1

   <ahaller2> +1

   <mlefranc> +1

   <ClausStadler> +1

   <SimonCox> +1

   <DanhLePhuoc> 0

   Resolved: Deprecate Device class in the alignment to SSN new

   <KJanowic> yes

   ahaller2: And now we need to discuss what the alignment is.
   … Device becoming a subclass of Platform is probably the most
   controversial

   <ahaller2> PROPOSED: Old Device is defined as a subclass of new
   Platform in the alignment

   <KJanowic> why controversial?

   <KJanowic> +1

   <ahaller2> +1

   <mlefranc> +1

   <ClausStadler> +1

   <KJanowic> it is what we are saying in different ways for 40min
   now :-)

   <SimonCox> +1

   <ahaller2> @KJanowic sloppy use of english, "not needed" maybe

   <DanhLePhuoc> 0

   Resolved: Old Device is defined as a subclass of new Platform
   in the alignment

   <KJanowic> we get this by transitivity

   <mlefranc> transitively entailed anyways

   <KJanowic> yes

   <KJanowic> let us move on

   <mlefranc> +1

   ahaller2: Do we still need a subclass relationship for the
   SensingDevice to Platform, or is transitivity enough?
   … I take it that we don't need it anymore.

   <KJanowic> the 'sensing'

   ahaller2: Then you want to remove "sensing" from the rdfs
   comment?

   KJanowic: I would drop "for sensing" so that you can have
   platforms for actuators for instance.

   <ahaller2> PROPOPSED: To drop "for sensing" out of the
   rdfs:comment in the System class

   <mlefranc> +61

   <ClausStadler> +1

   <mlefranc> +1

   <ahaller2> +1

   <KJanowic> "System is a unit of abstraction for pieces of
   infrastructure (and we largely care that they are) for sensing.
   A system has components, its subsystems, which are other
   systems." --> remove 'for sensing'

   <KJanowic> +1

   <SimonCox> +1

   <KJanowic> [hissing in the background]

   Resolved: To drop "for sensing" out of the rdfs:comment in the
   System class

   <DanhLePhuoc> +1

Progress on ACTION-302 for options in regards to Sensing class in SSN
new

   ACTION-302?

   <trackbot> ACTION-302 -- Krzysztof Janowicz to Propose options
   on sensing class for ssn new -- due 2017-04-11 -- OPEN

   <trackbot> [22]http://www.w3.org/2015/spatial/track/actions/302

     [22] http://www.w3.org/2015/spatial/track/actions/302

   <KJanowic> can we close issue 153? (and leave action 296 open
   until it is implemented)

   <KJanowic> [23]https://www.w3.org/2015/spatial/wiki/Sensing_SSN

     [23] https://www.w3.org/2015/spatial/wiki/Sensing_SSN

   <KJanowic> Should I move to action 302?

   KJanowic: Similar to the previous discussion.
   … The concept of Sensing has caused a lot of confusion in
   papers I wrote and elsewhere.
   … There are 2 ways you can think of sensing. To sense, the act
   of observation.
   … This would be observation now.
   … Other way is as a recipe.
   … Sensors are like implementations of sensing that describe how
   to do this. If this is your interpretation, we changed process
   to procedure. Then we end up with whether we need
   SensingProcedure, back to previous discussion.
   … So get rid of SensingProcedure.
   … [going through paper proposal]. Either event view or
   procedure view.
   … If somebody really insists, they can use the deprecated
   classes.

   ahaller2: Proposal to deprecate Sensing and make it a subclass
   of Procedure.

   KJanowic: Again, transitivity will give us that relationship.

   <KJanowic> "A ssn:Sensing is something that is a ssn:Process"
   --> same transitivity trick again

   mlefranc: No comment on my side, I'm ok with that.

   <ahaller2> PROPOSED: Deprecate Sensing class in alignment

   <mlefranc> [24]https://lists.w3.org/Archives/Public/
   public-sdw-wg/2017Apr/0132.html

     [24] https://lists.w3.org/Archives/Public/public-sdw-wg/2017Apr/0132.html

   <mlefranc> +1

   <KJanowic> +1

   <ahaller2> +1

   <DanhLePhuoc> +1

   <ahaller2> [25]https://github.com/w3c/sdw/blob/gh-pages/ssn/
   images/sample-relationship.png

     [25] https://github.com/w3c/sdw/blob/gh-pages/ssn/images/sample-relationship.png

   <ahaller2> [26]https://github.com/w3c/sdw/blob/gh-pages/ssn/
   images/sampling-activity.png

     [26] https://github.com/w3c/sdw/blob/gh-pages/ssn/images/sampling-activity.png

   SimonCox: I'm trying to find some reference material. I
   prepared 3 diagrams that laid out the Sampling, Actuation and
   Observation so that we could compare them

   <ahaller2> [27]https://github.com/w3c/sdw/tree/gh-pages/ssn/
   images

     [27] https://github.com/w3c/sdw/tree/gh-pages/ssn/images

   ahaller2: These diagrams are still valid

   <ahaller2> [28]https://github.com/w3c/sdw/blob/gh-pages/ssn/
   images/observation-activity.png

     [28] https://github.com/w3c/sdw/blob/gh-pages/ssn/images/observation-activity.png

   <KJanowic> [29]https://github.com/w3c/sdw/blob/gh-pages/ssn/
   images/actuation-activity.png

     [29] https://github.com/w3c/sdw/blob/gh-pages/ssn/images/actuation-activity.png

   <KJanowic> I can speak to that

   <KJanowic> they remain instances of process anywail by trivial
   entailment

   [Armin and Simon discussing background for this proposal]

   KJanowic: The proposal is simply to, when you wanted to talk
   about SensingProcedure, just talk about Procedure. And if you
   want to talk about activity, use the other classes.

   <SimonCox> +1

   Resolved: Deprecate Sensing class in alignment

   <KJanowic> yes, fine with me

   ahaller2: The alignment with DUL will probably need to be
   adjusted as well.

   Action: KJanowic to implement changes on Sensing,
   SensingDevice, Device, System and their alignment to DULCE

   <trackbot> Created ACTION-309 - Implement changes on sensing,
   sensingdevice, device, system and their alignment to dulce [on
   Krzysztof Janowicz - due 2017-04-18].

Deprecate ssn:SensorDataSheet as suggested in ISSUE-121

   <tidoust> ISSUE-121?

   <trackbot> ISSUE-121 -- Is ssn:SensorDataSheet needed? --
   raised

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

     [30] http://www.w3.org/2015/spatial/track/issues/121

sensor datasheet

   <KJanowic> [ a lot of hissing]

   mlefranc: looked for evidence of usage, didn't find any

   OK to deprec ate

   <mlefranc> (did not look for evidence of usage :-) )

   <mlefranc> [31]https://w3c.github.io/sdw/ssn-usage/

     [31] https://w3c.github.io/sdw/ssn-usage/

   <ahaller2> PROPOSED: Deprecate ssn:SensorDataSheet

   <mlefranc> +1

   <ahaller2> +1

   <KJanowic> 0

   +1

   <DanhLePhuoc> +1

   <ClausStadler> 0 (i missed out on the discussion)

   Resolved: Deprecate ssn:SensorDataSheet

   <KJanowic> no, it is a document

   <KJanowic> let us not align it. it is not a procedure

   ahaller2: Does the deprecated class need to be aligned ?

   <ahaller2> rdfs:comment from SensorDataSheet A data sheet
   records properties of a sensor. A data sheet might describe for
   example the accuracy in various conditions, the power use, the
   types of connectors that the sensor has, etc. Generally a
   sensor's properties are recorded directly (with
   hasMeasurementCapability, for example), but the data sheet can
   be used for example to record the manufacturers specifications
   verses observed capabilites, or if more

   <ahaller2> is known than the manufacturer specifies, etc. The
   data sheet is an information object about the sensor's
   properties, rather than a direct link to the actual properties
   themselves.

   KJanowic: datasheet was isolated from the rest of SSN

   mlefranc: only one appearance in document

   mlefranc: RDF graph that contains some information about the
   sensor

   mlefranc: simplify -> deprecate/remove

   mlefranc: no point to retain

Progress on ACTION-304 to investigate the need of a complex result
time property in SSN new

   ClausStadler: example usage used event structure similar to
   OWL-Time TemporalEntity

   ClausStadler: want resultTime to be an Instant

   ClausStadler: some confusion about relationships between
   temporal entities and instants

   <ahaller2> SimonCox: Temporalentities in OWL time have
   beginning and end

   SimonCox: there are various relationship available between
   temporal entities in OWL-Time

   <KJanowic> I think we are adding complexity on the wrong side
   of things

   SimonCox: should SSN be aligned with OWL-Time?

   KJanowic: resultTime has data-type property, more complex usage
   of OWL-Time temporal entities needs to be managed separatley

   <KJanowic> leave everything as is

   too much work now ...

   <KJanowic> we get the olw-time link via phenomenonTime anyway

   People are free to use TemporalEntity for phenomenonTime

   ClausStadler: alignment (Observation subclass of
   TemporalEntity) would be nice, but we are running out of time
   to do the documentation

   ahaller2: future issue ...

   <ahaller2> close ACTION-304

   <trackbot> Closed ACTION-304.

Progress on ACTION-273 for François Daoust to check whether we
can/should add licence statement to /ns docs and, if so, which one

   <tidoust> ACTION-273?

   <trackbot> ACTION-273 -- François Daoust to Look into whether
   we can/should add licence statement to /ns docs and, if so,
   which one -- due 2017-03-07 -- OPEN

   <trackbot> [32]http://www.w3.org/2015/spatial/track/actions/273

     [32] http://www.w3.org/2015/spatial/track/actions/273

   <tidoust> [33]Comments on license

     [33] https://lists.w3.org/Archives/Public/public-sdw-wg/2017Mar/0071.html

   <mlefranc> see also [34]https://lists.w3.org/Archives/Public/
   public-sdw-wg/2017Apr/0122.html

     [34] https://lists.w3.org/Archives/Public/public-sdw-wg/2017Apr/0122.html

   tidoust: don't mix licenses,: no conflict, just risk of
   confusion

   <tidoust> [35]Comments from Raul's colleague

     [35] https://www.w3.org/2015/spatial/wiki/Ontology_rights_and_licence#Comments_from_V.C3.ADctor_Rodr.C3.ADguez_Doncel

   mlefranc: Colleague wrote paper - OK to have a license on an
   ontology

   <KJanowic> [ I cannot understand Maxime due to hissing, sorry
   for that]

   ahaller2: we are already using dcterms namespace, prefer to
   cc:license

   <ahaller2> PROPOSED: Add licence statement referring to
   [36]https://www.w3.org/Consortium/Legal/2015/
   copyright-software-and-document in SOSA and SSN using
   dcterms:licence

     [36] https://www.w3.org/Consortium/Legal/2015/copyright-software-and-document

   <ahaller2> dcterms:licence

   <ahaller2> +1

   <ScottSimmons> OGC is removing "All rights reserved" from the
   license text

   <KJanowic> 0 (I have absolutely no expertise to comment on
   that)

   <mlefranc> 0, OGC to choose

   <mlefranc> +1 for dcterms: instead of cc:

   <tidoust> +1

   <KJanowic> Let us ask somebody else to decide about this. do we
   (in this group, right now) have the legal expertise to decide
   about this?

   <KJanowic> +1 to Simon

   SimonCox: licensing issues should not be decided by sub-group

   Resolved: Add licence statement referring to [37]https://
   www.w3.org/Consortium/Legal/2015/
   copyright-software-and-document in SOSA and SSN using
   dcterms:license

     [37] https://www.w3.org/Consortium/Legal/2015/copyright-software-and-document

   SimonCox: decision shoudl be made by SDWWG
   … in OWL ontology should use dcterms:license

Decision on whether Platforms may be attached to Platforms ISSUE-154

   <mlefranc> what about subSystemOf ? still open issue

   <ahaller2> [38]https://www.w3.org/2015/spatial/wiki/Terms

     [38] https://www.w3.org/2015/spatial/wiki/Terms

   <KJanowic> I tend to agree with that. We can make use of system
   here.

   <KJanowic> I can speak to that. There is an alternative path

   SimonCox: lots of flexibility is potentially required, need to
   allow data providers to provide as much or as little as they
   choose.
   … can we generalize hosts/hostedBy?

   <mlefranc> Jano, add a note about that in the rec ?

   <KJanowic> Yes, maybe. Or just one axiom

   KJanowic: explaining consequences of device/platform decision
   earlier: old - ssn:Device subclassOf ssn:System, new -
   sosa:Platform subclassOf sosa:System
   … this allows platforms on platforms etc?

   <KJanowic> see: "A ssn:System is something that is a
   DUL:PhysicalObject and has a ssn:hasOperatingRange property who
   must be a ssn:OperatingRange and has a ssn:hasSubSystem
   property who may be a ssn:System and has a ssn:hasSubSystem
   property who must be a ssn:System and has a ssn:hasDeployment
   property who must be a ssn:Deployment and has a
   ssn:hasSurvivalRange property who must be a ssn:SurvivalRange
   and has a ssn:onPlatform property who must be a ssn:Platform"

   <KJanowic> and "A ssn:Device is something that is a ssn:System
   and is a DUL:DesignedArtifact"

   KJanowic: get all the subsystem magic, composability etc

   <KJanowic> end of the week means 16th?

   <KJanowic> I have a procedual question

   <mlefranc> question is: is it possible that a system is be
   hosted on something it's not a subsystem of, and is it possible
   that a platform is a subsystem it's not hosted on ?

   <tidoust> [39]Timeline to REC

     [39] https://lists.w3.org/Archives/Public/public-sdw-wg/2017Mar/0231.html

   <KJanowic> Simon, sorry for interrupting you

   <tidoust> [In particular, I noted under "Publication of last
   WD" as pre-requisites that "Most substantive issues have been
   addressed. *A few minor ones may remain*"

   <KJanowic> My proposal for now: some platforms are systems. end
   of story

   <KJanowic> +1

   SimonCox: various composition patterns. Do we use a single
   predicate all the way down, or is there a special one for the
   stopping point?

   <KJanowic> +1 to Maxime (the part that I understood)

   (... is hosts sub-property of hasSubSystem?)

   <ahaller2> close ISSUE-154

   <trackbot> Closed ISSUE-154.

   Open world assumption allows us to use sub-system predicate

   <ahaller2> [40]https://www.w3.org/2015/spatial/wiki/Open_Issues

     [40] https://www.w3.org/2015/spatial/wiki/Open_Issues

   <KJanowic> Okay, I will be able to make it for the first 50min
   (and have to teach then)

   Tomorrows meeting is same time as tomorrow, just working
   through issue list

   ahaller2: Editors need to carry SSN documentation into the
   document

   ahaller2: do we need to state in a Wiki page how requirements
   have been addressed?

   tidoust: no W3C rule here - up to working group

   ahaller2: need stable document next week

   <tidoust> [regrets for tomorrow's call]

   KJanowic: OK to submit final draft next week?

   tidoust: no-one can pull plug except WG

   tidoust: OWL-Time has started wide review prior to final
   document
   … no longer a 'last call' document,
   … start wide-review asap, but document needs to be good anough
   … publication of document can be delayed until end of next week
   - do-able

   KJanowic: delay document risks cutting into time for the other
   aspects

   tidoust: get complete document beginning of next week in order
   to trigger wide-review
   … aim at 18th?

   <KJanowic> works for me :-)

   (17th Hawaii time)

   KJanowic: what about naming?

   ahaller2: tomorrow in issue resolution

   <KJanowic> I like the silence :-)

   ahaller2: leave as is, and wait for review (to resolve naming
   issue)

   <KJanowic> Thanks

   ahaller2: editors to confer over email

   <ahaller2> thanks, bye

Summary of Action Items

    1. [41]KJanowic to implement changes on Sensing,
       SensingDevice, Device, System and their alignment to DULCE

Summary of Resolutions

    1. [42]Deprecate SensingDevice class in the alignment to SSN
       new
    2. [43]Deprecate Device class in the alignment to SSN new
    3. [44]Old Device is defined as a subclass of new Platform in
       the alignment
    4. [45]To drop "for sensing" out of the rdfs:comment in the
       System class
    5. [46]Deprecate Sensing class in alignment
    6. [47]Deprecate ssn:SensorDataSheet
    7. [48]Add licence statement referring to https://www.w3.org/
       Consortium/Legal/2015/copyright-software-and-document in
       SOSA and SSN using dcterms:license
Received on Wednesday, 12 April 2017 15:01:12 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 12 April 2017 15:01:12 UTC