- From: Francois Daoust <fd@w3.org>
- Date: Wed, 12 Apr 2017 17:00:57 +0200
- To: <public-sdw-wg@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