– DRAFT –
Spatial Data on the Web SSN Group Teleconference
11 April 2017
<KJanowic> +1
<ahaller2> +1
+1
<ScottSimmons> +0
<mlefranc> +1
<DanhLePhuoc> +1
[Armin goes through the patent call]
ACTION-296?
<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
<trackbot> http://www.w3.org/2015/spatial/track/actions/296
<KJanowic> 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> 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
ACTION-302?
<trackbot> ACTION-302 -- Krzysztof Janowicz to Propose options on sensing class for ssn new -- due 2017-04-11 -- OPEN
<trackbot> 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> 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> https://lists.w3.org/Archives/Public/public-sdw-wg/2017Apr/0132.html
<mlefranc> +1
<KJanowic> +1
<ahaller2> +1
<DanhLePhuoc> +1
<ahaller2> https://github.com/w3c/sdw/blob/gh-pages/ssn/images/sample-relationship.png
<ahaller2> 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> https://github.com/w3c/sdw/tree/gh-pages/ssn/images
ahaller2: These diagrams are still valid
<ahaller2> https://github.com/w3c/sdw/blob/gh-pages/ssn/images/observation-activity.png
<KJanowic> 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].
<tidoust> ISSUE-121?
<trackbot> ISSUE-121 -- Is ssn:SensorDataSheet needed? -- raised
<trackbot> http://www.w3.org/2015/spatial/track/issues/121
<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> 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
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.
<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> http://www.w3.org/2015/spatial/track/actions/273
<tidoust> Comments on license
<mlefranc> see also https://lists.w3.org/Archives/Public/public-sdw-wg/2017Apr/0122.html
tidoust: don't mix licenses,: no conflict, just risk of confusion
<tidoust> Comments from Raul's colleague
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 https://www.w3.org/Consortium/Legal/2015/copyright-software-and-document in SOSA and SSN using dcterms:licence
<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 https://www.w3.org/Consortium/Legal/2015/copyright-software-and-document in SOSA and SSN using dcterms:license
SimonCox: decision shoudl be made by SDWWG
… in OWL ontology should use dcterms:license
<mlefranc> what about subSystemOf ? still open issue
<ahaller2> 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> Timeline to REC
<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> 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
