Spatial Data on the Web SSN Group Teleconference

11 April 2017

Meeting Minutes

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

<KJanowic> +1

<ahaller2> +1


<ScottSimmons> +0

<mlefranc> +1

<DanhLePhuoc> +1

patent call 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


<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

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


<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].

Deprecate ssn:SensorDataSheet as suggested in ISSUE-121

<tidoust> ISSUE-121?

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

<trackbot> 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> https://‌w3c.github.io/‌sdw/‌ssn-usage/

<ahaller2> PROPOSED: Deprecate ssn:SensorDataSheet

<mlefranc> +1

<ahaller2> +1

<KJanowic> 0


<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> 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

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

<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

Summary of Action Items

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

Summary of Resolutions

  1. Deprecate SensingDevice class in the alignment to SSN new
  2. Deprecate Device class in the alignment to SSN new
  3. Old Device is defined as a subclass of new Platform in the alignment
  4. To drop "for sensing" out of the rdfs:comment in the System class
  5. Deprecate Sensing class in alignment
  6. Deprecate ssn:SensorDataSheet
  7. Add licence statement referring to https://‌www.w3.org/‌Consortium/‌Legal/‌2015/‌copyright-software-and-document in SOSA and SSN using dcterms:license
Minutes formatted by Bert Bos's scribe.perl version 2.18 (2017/03/20 18:51:04), a reimplementation of David Booth's scribe.perl. See CVS log.