20:01:01 <RRSAgent> RRSAgent has joined #sdwssn
20:01:01 <RRSAgent> logging to http://www.w3.org/2017/04/11-sdwssn-irc
20:01:03 <trackbot> RRSAgent, make logs world
20:01:03 <Zakim> Zakim has joined #sdwssn
20:01:05 <trackbot> Zakim, this will be SDW
20:01:05 <Zakim> ok, trackbot
20:01:06 <trackbot> Meeting: Spatial Data on the Web Working Group Teleconference
20:01:06 <trackbot> Date: 11 April 2017
20:01:32 <tidoust> s/Working Group/SSN Group/
20:02:56 <KJanowic> present+
20:02:58 <tidoust> Present+ Francois
20:03:04 <tidoust> Agenda: https://www.w3.org/2015/spatial/wiki/Meetings:SSN-Telecon20170411
20:03:08 <tidoust> Chair: Armin
20:03:23 <ScottSimmons> present+ ScottSimmons
20:03:36 <ahaller2> present+ ahaller2
20:03:42 <ChrisLittle> ChrisLittle has joined #sdwssn
20:04:04 <ChrisLittle> present+ ChrisLittle
20:06:28 <DanhLePhuoc> DanhLePhuoc has joined #sdwssn
20:07:48 <mlefranc> mlefranc has joined #sdwssn
20:08:17 <mlefranc> present+
20:09:00 <ahaller2> scribe: tidoust
20:09:05 <ahaller2> scribenick: tidoust
20:09:11 <ahaller2> topic: Approve last week’s minutes https://www.w3.org/2017/03/28-sdwssn-minutes
20:09:14 <SimonCox> SimonCox has joined #sdwssn
20:09:23 <KJanowic> +1
20:09:25 <ahaller2> +1
20:09:26 <tidoust> +1
20:10:03 <ScottSimmons> +0
20:10:06 <mlefranc> +1
20:10:06 <DanhLePhuoc> +1
20:10:15 <DanhLePhuoc> present+ DanhLePhuoc
20:10:19 <ahaller2> topic: patent call https://www.w3.org/2015/spatial/wiki/Patent_Call
20:10:43 <tidoust> [Armin goes through the patent call]
20:10:56 <ahaller2> topic: Progress on ACTION-296 to address role of device class as of ISSUE-153 and propose a solution
20:11:01 <tidoust> ACTION-296?
20:11:01 <trackbot> ACTION-296 -- Krzysztof Janowicz to Look into https://www.w3.org/2015/spatial/track/issues/153 and propose a solution -- due 2017-04-11 -- OPEN
20:11:01 <trackbot> http://www.w3.org/2015/spatial/track/actions/296
20:11:17 <SimonCox> present+
20:11:26 <KJanowic> https://www.w3.org/2015/spatial/wiki/Link_between_platform_and_device
20:11:28 <KJanowic> q+
20:11:33 <ahaller2> ack KJanowic
20:12:11 <tidoust> KJanowic: Question about what to do with the class Device, Sensing.
20:12:19 <tidoust> ... There was a sentiment that we could get rid of Device
20:13:08 <tidoust> ... 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.
20:13:23 <tidoust> ... We should drop SensibleDevice.
20:13:24 <ClausStadler> ClausStadler has joined #sdwssn
20:13:32 <tidoust> s/SensibleDevice/SensingDevice/
20:13:55 <tidoust> ... The second part is the Device class itself, declared to be physical.
20:14:23 <tidoust> ... The notion of Platform has moved to Sensor, so you could argue that we don't need Device anymore.
20:14:29 <ClausStadler> present+ ClausStadler
20:14:43 <tidoust> ... Idea is to keep Platform as a superclass of Device.
20:14:58 <mlefranc> q+
20:15:05 <tidoust> ... 3 steps:
20:15:09 <tidoust> ... 1/ Drop SensingDevice
20:15:28 <ahaller2> q?
20:15:50 <ahaller2> ack mlefranc
20:15:50 <tidoust> ... [missed other 2 steps]
20:15:56 <SimonCox> q+
20:16:18 <KJanowic> q+
20:16:22 <tidoust> mlefranc: I fully agree. One question is what happens with some people that used oldSSN and made some difference between Device and System.
20:16:32 <tidoust> ... Maybe these people will react during the wide review of the specification.
20:16:45 <KJanowic> no, not exactly
20:16:54 <tidoust> ... Device and System would be somehow merged, right?
20:16:54 <KJanowic> most of device are now platform
20:17:26 <tidoust> KJanowic: Most of Device is now fully captured by Platform.
20:17:37 <SimonCox> q-
20:17:51 <SimonCox> q+
20:18:01 <tidoust> ... The rest can be captured by System, or you can use Device, it's just deprecated.
20:18:10 <tidoust> ... You can also add your own subclasses.
20:18:26 <SimonCox> are we just simplifying sensor/device/platform/system arrangement here? Too many special words ... ?
20:18:28 <tidoust> ... I don't think we're missing something, but maybe somebody will bring something forward that we haven't considered.
20:18:29 <mlefranc> ok, totally agree
20:18:48 <KJanowic> subclass
20:18:56 <ahaller2> q?
20:18:59 <tidoust> ahaller2: SensingDevice, if we deprecate it, should we make it a subclass of Platform?
20:19:00 <ahaller2> ack KJanowic
20:19:02 <ahaller2> ack SimonCox
20:19:22 <KJanowic> platforms are not necessarily physical.
20:19:54 <KJanowic> yes, simplifying sensor/device/platform/system and making sure we fully include actuators and samplers
20:19:57 <tidoust> 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.
20:20:00 <KJanowic> q+
20:20:04 <tidoust> ... Is it the case?
20:20:42 <tidoust> 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.
20:20:50 <KJanowic> q+
20:20:55 <tidoust> ... SensingDevice would just be a subclass of the Platform class.
20:21:24 <tidoust> SimonCox: OK, the word SensingDevice has always confused me. If that can help simplify this, that's great.
20:21:32 <ahaller2> q?
20:21:32 <mlefranc> q+
20:21:37 <ahaller2> ack KJanowic
20:21:44 <tidoust> ahaller2: I was also confused by the difference between SensingDevice and Sensor initially, indeed.
20:22:35 <tidoust> 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.
20:22:50 <tidoust> ... We are just cleaning up here.
20:22:50 <ahaller2> q?
20:23:50 <tidoust> SimonCox: Then I probably need to review the O&M alignment with the work we've done on Sampling.
20:24:31 <ahaller2> ack mlefranc
20:25:07 <KJanowic> no, they are in subclass relation
20:25:11 <KJanowic> q+
20:25:21 <ahaller2> ack KJanowic
20:25:30 <tidoust> 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?
20:25:33 <tidoust> ahaller2: Yes.
20:26:12 <ahaller2> q?
20:26:18 <tidoust> KJanowic: Sensor and Sensing devices are now very close, but there are no non physical sensing devices. You cannot have a smartphone simulation.
20:26:59 <ahaller2> PROPOSED: Deprecate SensingDevice class in the alignment to SSN new and make it a subclass of sosa:Platform
20:27:08 <KJanowic> +1
20:27:11 <ahaller2> +1
20:27:13 <ClausStadler> +1
20:27:24 <mlefranc> 0
20:27:54 <KJanowic> q+
20:28:03 <KJanowic> could be both, it is an even split :-)
20:28:10 <ahaller2> ack KJanowic
20:28:20 <tidoust> mlefranc: I don't really understand why it's a subclass of Platform and not a subclass of Sensor. It might be both, actually.
20:28:30 <SimonCox> The word 'Device' is overloaded in 2017 :-(
20:28:40 <DanhLePhuoc> 0
20:28:55 <mlefranc> ok
20:29:09 <tidoust> KJanowic: The device is what matters in the end, I think, but it's really a tiny decision.
20:29:12 <SimonCox> q+
20:29:18 <ahaller2> ack SimonCox
20:29:26 <tidoust> ahaller2: It does not really hurt if we add another subclass relationship.
20:29:56 <tidoust> 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.
20:30:03 <KJanowic> Just FYI : "SensingDevice  A sensing device is a device that implements sensing."
20:30:12 <KJanowic> q+
20:30:44 <tidoust> ... 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.
20:30:58 <mlefranc> q+
20:31:14 <tidoust> ... It may be that some of the words that we end up using in the ontology are not the ones we would use naturally.
20:31:16 <ahaller2> ack KJanowic
20:31:46 <tidoust> KJanowic: What I like to do in this case, is to look at axioms and syntactic, and forget about the terms themselves.
20:32:15 <DanhLePhuoc> q+
20:32:18 <tidoust> ... [going through axiomatization links]
20:32:44 <tidoust> ... From a purely logical perspective, we could deprecate the term without even introducing a subclass relationship.
20:32:51 <DanhLePhuoc> https://www.w3.org/TR/generic-sensor/
20:32:55 <tidoust> ... We have it through transitivity already.
20:33:18 <ahaller2> PROPOSED: Deprecate SensingDevice class in the alignment to SSN new
20:33:25 <tidoust> ahaller2: OK, then I need to rephrase the proposal
20:33:25 <mlefranc> q-
20:33:26 <mlefranc> +1
20:33:28 <ahaller2> +1
20:33:41 <mlefranc> agreed
20:33:46 <DanhLePhuoc> 0
20:33:48 <SimonCox> +1
20:33:51 <ClausStadler> +1
20:33:52 <KJanowic> +1
20:34:09 <tidoust> ack DanhLePhuoc
20:34:12 <ahaller2> ack DanhLePhuoc
20:34:30 <tidoust> DanhLePhuoc: Generic sensor API has a definition of Sensor and Device.
20:34:43 <tidoust> ... Sensor is attached to Device.
20:34:48 <KJanowic> Yes, we have exactly the same ~idea using the relation of sensor to platform
20:34:49 <KJanowic> q+
20:35:29 <tidoust> ... Some projects have been using SensingDevice to represent that
20:35:32 <KJanowic> the attachment is now modeled by the relation of sensors to platforms
20:36:11 <tidoust> 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.
20:36:48 <tidoust> ... 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.
20:36:53 <ahaller2> q?
20:37:00 <tidoust> ... They use Device the same way as we use Platform.
20:37:10 <ahaller2> RESOLVED: Deprecate SensingDevice class in the alignment to SSN new
20:37:14 <ahaller2> ack KJanowic
20:37:42 <tidoust> KJanowic: The attachment thing is now with Platform, so it's still there.
20:38:14 <tidoust> ... For Platform, you're interested in the geometry of things.
20:38:27 <ahaller2> PROPOSED: Deprecate Device class in the alignment to SSN new
20:38:32 <KJanowic> +1
20:38:44 <ahaller2> +1
20:38:50 <mlefranc> +1
20:39:19 <ClausStadler> +1
20:39:34 <SimonCox> +1
20:39:39 <DanhLePhuoc> 0
20:40:00 <ahaller2> RESOLVED: Deprecate Device class in the alignment to SSN new
20:40:15 <KJanowic> yes
20:40:17 <tidoust> ahaller2: And now we need to discuss what the alignment is.
20:40:32 <tidoust> ... Device becoming a subclass of Platform is probably the most controversial
20:40:46 <ahaller2> PROPOSED: Old Device is defined as a subclass of new Platform in the alignment
20:40:50 <KJanowic> why controversial?
20:40:51 <KJanowic> +1
20:41:05 <ahaller2> +1
20:41:17 <mlefranc> +1
20:41:20 <ClausStadler> +1
20:41:25 <KJanowic> it is what we are saying in different ways for 40min now :-)
20:41:29 <SimonCox> +1
20:41:40 <ahaller2> @KJanowic sloppy use of english, "not needed" maybe
20:41:41 <DanhLePhuoc> 0
20:41:54 <ahaller2> RESOLVED: Old Device is defined as a subclass of new Platform in the alignment
20:42:09 <KJanowic> we get this by transitivity
20:42:15 <mlefranc> transitively entailed anyways
20:42:20 <KJanowic> yes
20:42:24 <KJanowic> let us move on
20:42:27 <mlefranc> +1
20:42:27 <ahaller2> q?
20:42:30 <tidoust> ahaller2: Do we still need a subclass relationship for the SensingDevice to Platform, or is transitivity enough?
20:42:37 <ahaller2> q?
20:42:48 <tidoust> ... I take it that we don't need it anymore.
20:42:50 <KJanowic> the 'sensing'
20:42:54 <ahaller2> q?
20:43:08 <tidoust> ... Then you want to remove "sensing" from the rdfs comment?
20:43:34 <tidoust> KJanowic: I would drop "for sensing" so that you can have platforms for actuators for instance.
20:43:42 <ahaller2> PROPOPSED: To drop "for sensing" out of the rdfs:comment in the System class
20:43:52 <mlefranc> +61
20:43:53 <ClausStadler> +1
20:43:55 <mlefranc> +1
20:43:58 <ahaller2> +1
20:44:02 <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'
20:44:10 <KJanowic> +1
20:44:20 <SimonCox> +1
20:44:23 <KJanowic> [hissing in the background]
20:44:27 <ahaller2> RESOLVED: To drop "for sensing" out of the rdfs:comment in the System class
20:44:37 <DanhLePhuoc> +1
20:44:46 <ahaller2> topic: Progress on ACTION-302 for options in regards to Sensing class in SSN new
20:44:48 <tidoust> ACTION-302?
20:44:48 <trackbot> ACTION-302 -- Krzysztof Janowicz to Propose options on sensing class for ssn new -- due 2017-04-11 -- OPEN
20:44:48 <trackbot> http://www.w3.org/2015/spatial/track/actions/302
20:44:53 <KJanowic> can we close issue 153? (and leave action 296 open until it is implemented)
20:44:55 <KJanowic> q+
20:45:05 <ahaller2> ack KJanowic
20:45:26 <KJanowic> https://www.w3.org/2015/spatial/wiki/Sensing_SSN
20:45:46 <KJanowic> Should I move to action 302?
20:46:35 <tidoust> KJanowic: Similar to the previous discussion.
20:46:53 <tidoust> ... The concept of Sensing has caused a lot of confusion in papers I wrote and elsewhere.
20:47:27 <tidoust> ... There are 2 ways you can think of sensing. To sense, the act of observation.
20:47:34 <tidoust> ... This would be observation now.
20:47:43 <tidoust> ... Other way is as a recipe.
20:48:39 <tidoust> ... 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.
20:49:01 <tidoust> ... So get rid of SensingProcedure.
20:50:14 <tidoust> ... [going through paper proposal]. Either event view or procedure view.
20:50:35 <tidoust> ... If somebody really insists, they can use the deprecated classes.
20:50:49 <ahaller2> q?
20:51:17 <tidoust> ahaller2: Proposal to deprecate Sensing and make it a subclass of Procedure.
20:51:36 <tidoust> KJanowic: Again, transitivity will gives us that relationship.
20:51:42 <tidoust> s/gives us/give us/
20:51:47 <KJanowic> "A ssn:Sensing is something that is a ssn:Process" --> same transitivity trick again
20:51:50 <ahaller2> q?
20:52:04 <ahaller2> q?
20:52:11 <tidoust> mlefranc: No comment on my side, I'm ok with that.
20:52:25 <ahaller2> PROPOSED: Deprecate Sensing class in alignment
20:52:26 <mlefranc> https://lists.w3.org/Archives/Public/public-sdw-wg/2017Apr/0132.html
20:52:28 <mlefranc> +1
20:52:29 <KJanowic> +1
20:52:33 <ahaller2> +1
20:52:38 <DanhLePhuoc> +1
20:54:56 <ahaller2> https://github.com/w3c/sdw/blob/gh-pages/ssn/images/sample-relationship.png
20:55:14 <ahaller2> https://github.com/w3c/sdw/blob/gh-pages/ssn/images/sampling-activity.png
20:55:26 <tidoust> 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
20:55:43 <ahaller2> https://github.com/w3c/sdw/tree/gh-pages/ssn/images
20:56:03 <tidoust> ahaller2: These diagrams are still valid
20:56:08 <ahaller2> https://github.com/w3c/sdw/blob/gh-pages/ssn/images/observation-activity.png
20:56:40 <KJanowic> https://github.com/w3c/sdw/blob/gh-pages/ssn/images/actuation-activity.png
20:56:43 <KJanowic> q+
20:56:52 <KJanowic> I can speak to that
20:57:48 <KJanowic> they remain instances of process anywail by trivial entailment
20:57:49 <ahaller2> q?
20:57:52 <ahaller2> ack KJanowic
20:57:54 <tidoust> [Armin and Simon discussing background for this proposal]
20:59:18 <tidoust> 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.
20:59:36 <SimonCox> +1
20:59:44 <ahaller2> RESOLVED: Deprecate Sensing class in alignment
20:59:54 <KJanowic> yes, fine with me
21:00:25 <tidoust> ahaller2: The alignment with DUL will probably need to be adjusted as well.
21:00:48 <ahaller2> ACTION: KJanowic to implement changes on Sensing, SensingDevice, Device, System and their alignment to DULCE
21:00:48 <trackbot> Created ACTION-309 - Implement changes on sensing, sensingdevice, device, system and their alignment to dulce [on Krzysztof Janowicz - due 2017-04-18].
21:01:24 <ahaller2> scribe: SimonCox
21:01:29 <ahaller2> scribenick: SimonCox
21:01:34 <tidoust> RRSAgent, draft minutes v2
21:01:34 <RRSAgent> I have made the request to generate http://www.w3.org/2017/04/11-sdwssn-minutes.html tidoust
21:01:40 <ahaller2> topic: Progress on ACTION-296 to address role of device class as of ISSUE-153 and propose a solution
21:01:54 <ahaller2> topic: Deprecate ssn:SensorDataSheet as suggested in ISSUE-121
21:01:55 <tidoust> s/topic: Progress on ACTION-296 to address role of device class as of ISSUE-153 and propose a solution//
21:02:03 <tidoust> ISSUE-121?
21:02:03 <trackbot> ISSUE-121 -- Is ssn:SensorDataSheet needed? -- raised
21:02:03 <trackbot> http://www.w3.org/2015/spatial/track/issues/121
21:02:21 <SimonCox> topic: sensor datasheet
21:02:51 <KJanowic> [ a lot of hissing]
21:02:52 <SimonCox> mlefranc: looked for evidence of usage, didn't find any
21:03:06 <SimonCox> OK to deprec ate
21:03:09 <mlefranc> (did not look for evidence of usage :-) )
21:04:27 <mlefranc> https://w3c.github.io/sdw/ssn-usage/
21:04:36 <ahaller2> q?
21:05:10 <ahaller2> PROPOSED: Deprecate ssn:SensorDataSheet
21:05:14 <mlefranc> +1
21:05:17 <ahaller2> +1
21:05:33 <KJanowic> 0
21:05:45 <SimonCox> +1
21:06:30 <DanhLePhuoc> +1
21:06:40 <ClausStadler> 0 (i missed out on the discussion)
21:06:52 <ahaller2> RESOLVED: Deprecate ssn:SensorDataSheet
21:07:05 <tidoust> Regrets: Raul, Kerry, Sefki
21:07:11 <KJanowic> no, it is a document
21:07:23 <KJanowic> let us not align it. it is not a procedure
21:07:38 <SimonCox> ahaller2: Does the deprecated class need to be aligned ?
21:07:53 <KJanowic> q+
21:08:06 <ahaller2> ack KJanowic
21:08:21 <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
21:08:23 <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.
21:08:40 <SimonCox> KJanowic: datasheet was isolated from the rest of SSN
21:08:46 <mlefranc> q+
21:08:51 <ahaller2> ack mlefranc
21:09:37 <SimonCox> mlefranc: only one appearance in document
21:10:06 <SimonCox> mlefranc: RDF graph that contains some information about the sensor
21:10:24 <SimonCox> mlefranc: simplify -> deprecate/remove
21:10:29 <ahaller2> Q?
21:10:36 <SimonCox> mlefranc: no point to retain
21:10:44 <ahaller2> topic: Progress on ACTION-304 to investigate the need of a complex result time property in SSN new
21:12:09 <SimonCox> ClausStadler: example usage used event structure similar to OWL-Time TemporalEntity
21:12:45 <SimonCox> ClausStadler: want resultTime to be an Instant
21:13:47 <SimonCox> ClausStadler: some confusion about relationships between temporal entities and instants
21:13:48 <KJanowic> q+
21:13:49 <SimonCox> q+
21:13:55 <KJanowic> q-
21:13:56 <KJanowic> q+
21:14:36 <ahaller2> ack SimonCox
21:15:15 <ahaller2> SimonCox: Temporalentities in OWL time have beginning and end
21:17:55 <SimonCox> SimonCox: there are various relationship available between temporal entities in OWL-Time
21:18:04 <SimonCox> q+
21:18:46 <KJanowic> I think we are adding complexity on the wrong side of things
21:20:07 <ahaller2> ack KJanowic
21:20:14 <ahaller2> ack SimonCox
21:20:50 <SimonCox> SimonCox: should SSN be aligned with OWL-Time?
21:21:19 <ahaller2> q?
21:21:30 <SimonCox> KJanowic: resultTime has data-type property, more complex usage of OWL-Time temporal entities needs to be managed separatley
21:21:30 <KJanowic> leave everything as is
21:21:38 <SimonCox> too much work now ...
21:21:46 <ahaller2> q?
21:21:48 <KJanowic> we get the olw-time link via phenomenonTime anyway
21:22:17 <ahaller2> q?
21:22:23 <SimonCox> People are free to use TemporalEntity for phenomenonTime
21:23:11 <SimonCox> ClausStadler: alignment (Observation subclass of TemporalEntity) would be nice, but we are running out of time to do the documentation
21:23:24 <ahaller2> q?
21:23:57 <SimonCox> ahaller2: future issue ...
21:24:00 <ahaller2> close ACTION-304
21:24:00 <trackbot> Closed ACTION-304.
21:24:11 <ahaller2> topic: 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
21:24:17 <tidoust> ACTION-273?
21:24:17 <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
21:24:17 <trackbot> http://www.w3.org/2015/spatial/track/actions/273
21:24:53 <tidoust> -> https://lists.w3.org/Archives/Public/public-sdw-wg/2017Mar/0071.html Comments on license
21:25:38 <mlefranc> see also https://lists.w3.org/Archives/Public/public-sdw-wg/2017Apr/0122.html
21:26:07 <SimonCox> tidoust: don't mix licenses,: no conflict, just risk of confusion
21:26:16 <ahaller2> q?
21:26:44 <tidoust> -> https://www.w3.org/2015/spatial/wiki/Ontology_rights_and_licence#Comments_from_V.C3.ADctor_Rodr.C3.ADguez_Doncel Comments from Raul's colleague
21:26:56 <SimonCox> mlefranc: Colleague wrote paper - OK to have a license on an ontology
21:27:07 <KJanowic> [ I cannot understand Maxime due to hissing, sorry for that]
21:27:58 <ahaller2> q?
21:28:08 <SimonCox> ahaller2: we are already using dcterms namespace, prefer to cc:license
21:28:14 <ahaller2> q?
21:28:54 <ahaller2> PROPOSED: Add licence statement referring to https://www.w3.org/Consortium/Legal/2015/copyright-software-and-document in SOSA and SSN using dcterms:license
21:29:04 <ahaller2> dcterms:licence
21:29:16 <ahaller2> s/license/licence
21:29:17 <ahaller2> +1
21:29:21 <ScottSimmons> OGC is removing "All rights reserved" from the license text
21:29:25 <KJanowic> 0 (I have absolutely no expertise to comment on that)
21:29:32 <mlefranc> 0, OGC to choose
21:29:54 <mlefranc> +1 for dcterms: instead of cc:
21:29:57 <tidoust> +1
21:32:05 <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?
21:32:38 <KJanowic> +1 to Simon
21:32:50 <ahaller2> q?
21:32:52 <SimonCox> SimonCox: licensing issues should not be decided by sub-group
21:33:15 <ahaller2> RESOLVED: Add licence statement referring to https://www.w3.org/Consortium/Legal/2015/copyright-software-and-document in SOSA and SSN using dcterms:license
21:33:16 <SimonCox> ... decision shoudl be made by SDWWG
21:33:34 <SimonCox> ... in OWL ontology should use dcterms:license
21:33:37 <ahaller2> topic: Decision on whether Platforms may be attached to Platforms ISSUE-154
21:34:18 <mlefranc> what about subSystemOf ? still open issue
21:34:19 <ahaller2> q?
21:34:24 <SimonCox> q+
21:34:54 <ahaller2> https://www.w3.org/2015/spatial/wiki/Terms
21:35:22 <KJanowic> I tend to agree with that. We can make use of system here.
21:35:32 <ahaller2> ack SimonCox
21:35:59 <KJanowic> q+
21:37:23 <KJanowic> I can speak to that. There is an alternative path
21:37:44 <KJanowic> q+
21:38:04 <SimonCox> SimonCox: lots of flexibility is potentially required, need to allow data providers to provide as much or as little as they choose.
21:38:09 <ahaller2> ack KJanowic
21:38:21 <SimonCox> ... can we generalize hosts/hostedBy?
21:40:08 <mlefranc> Jano, add a note about that in the rec ?
21:40:31 <KJanowic> Yes, maybe. Or just one axiom
21:41:02 <SimonCox> KJanowic: explaining consequences of device/platform decision earlier: old - ssn:Device subclassOf ssn:System, new - sosa:Platform subclassOf sosa:System
21:41:18 <ahaller2> q?
21:41:21 <SimonCox> ... this allows platforms on platforms etc?
21:41:34 <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"
21:41:43 <ahaller2> q?
21:41:52 <KJanowic> and "A ssn:Device is something that is a ssn:System and is a DUL:DesignedArtifact"
21:42:24 <KJanowic> q+
21:42:32 <SimonCox> q+
21:42:35 <ahaller2> ack KJanowic
21:43:26 <SimonCox> KJanowic: get all the subsystem magic, composability etc
21:44:45 <KJanowic> end of the week means 16th?
21:45:16 <KJanowic> q+
21:45:46 <KJanowic> I have a procedual question
21:46:10 <ahaller2> ack KJanowic
21:48:46 <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 ?
21:48:49 <tidoust> -> https://lists.w3.org/Archives/Public/public-sdw-wg/2017Mar/0231.html Timeline to REC
21:48:51 <ahaller2> ack SimonCox
21:49:02 <KJanowic> Simon, sorry for interrupting you
21:49:45 <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*"
21:49:54 <KJanowic> My proposal for now: some platforms are systems. end of story
21:49:57 <mlefranc> q+
21:50:07 <KJanowic> +1
21:50:12 <ahaller2> ack mlefranc
21:50:57 <SimonCox> SimonCox: various composition patterns. Do we use a single predicate all the way down, or is there a special one for the stopping point?
21:51:10 <KJanowic> +1 to Maxime (the part that I understood)
21:51:37 <SimonCox> (... is hosts sub-property of hasSubSystem?)
21:51:58 <ahaller2> close ISSUE-154
21:51:58 <trackbot> Closed ISSUE-154.
21:52:27 <SimonCox> Open world assumption allows us to use sub-system predicate
21:52:40 <ahaller2>  https://www.w3.org/2015/spatial/wiki/Open_Issues
21:52:53 <KJanowic> Okay, I will be able to make it for the first 50min (and have to teach then)
21:53:01 <SimonCox> Tomorrows meeting is same time as tomorrow, just working through issue list
21:53:22 <KJanowic> q+
21:53:44 <KJanowic> q-
21:53:44 <SimonCox> ahaller2: Editors need to carry SSN documentation into the document
21:54:17 <SimonCox> ahaller2: do we need to state in a Wiki page how requirements have been addressed?
21:54:38 <SimonCox> tidoust: no W3C rule here - up to working group
21:54:56 <KJanowic> q+
21:55:04 <SimonCox> ahaller2: need stable document next week
21:55:28 <ahaller2> ack KJanowic
21:55:31 <tidoust> [regrets for tomorrow's call]
21:55:49 <mlefranc> q+
21:55:52 <SimonCox> KJanowic: OK to submit final draft next week?
21:56:07 <SimonCox> tidoust: no-one can pull plug except WG
21:56:31 <SimonCox> tidoust: OWL-Time has started wide review prior to final document
21:56:58 <SimonCox> ... no longer a 'last call' document,
21:57:11 <SimonCox> ... start wide-review asap, but document needs to be good anough
21:57:35 <SimonCox> ... publication of document can be delayed until end of next week - do-able
21:58:06 <SimonCox> KJanowic: delay document risks cutting into time for the other aspects
21:58:22 <SimonCox> tidoust: get complete document beginning of next week in order to trigger wide-review
21:58:46 <SimonCox> ... aim at 18th?
21:59:07 <KJanowic> works for me :-)
21:59:17 <SimonCox> (17th Hawaii time)
21:59:51 <SimonCox> KJanowic: what about naming?
22:00:04 <SimonCox> ahaller2: tomorrow in issue resolution
22:00:12 <KJanowic> I like the silence :-)
22:00:22 <mlefranc> q+
22:00:25 <SimonCox> ahaller2: leave as is, and wait for review (to resolve naming issue)
22:00:31 <KJanowic> Thanks
22:00:58 <SimonCox> ... editors to confer over email
22:01:19 <ahaller2> thanks, bye
22:01:26 <tidoust> RRSAgent, draft minutes v2
22:01:26 <RRSAgent> I have made the request to generate http://www.w3.org/2017/04/11-sdwssn-minutes.html tidoust
22:01:33 <mlefranc> thank you bye
22:01:36 <KJanowic> bye bye
22:01:54 <ChrisLittle> bye
23:11:14 <ahalle___> ahalle___ has joined #sdwssn