- From: Phil Archer <phila@w3.org>
- Date: Wed, 13 Jul 2016 16:10:36 +0100
- To: SDW WG Public List <public-sdw-wg@w3.org>
The minutes of this week's SSN meeting are at
https://www.w3.org/2016/07/12-sdwssn-minutes with a snapshot below.
[1]W3C
[1] http://www.w3.org/
Spatial Data on the Web SSN Sub Group Teleconference
12 Jul 2016
See also: [2]IRC log
[2] http://www.w3.org/2016/07/12-sdwssn-irc
Attendees
Present
kerry, KJanowic, SimonCox, DanhLePhuoc, roba,
RaulGarciaCastro, scottsimmons
Regrets
Chair
kerry
Scribe
KJanowic
Contents
* [3]Topics
1. [4]patent call
https://www.w3.org/2015/spatial/wiki/Patent_Call
2. [5]SSN Requirements from UCR
3. [6]ISSUE-20 Reference external vocabularies
4. [7]ISSUE-24 clarification of lightweight APIs
requirement
5. [8]Suggested changes to ontology editing
process/tooling
6. [9]SOSA/SANDA?
* [10]Summary of Action Items
* [11]Summary of Resolutions
__________________________________________________________
I can scribe
:-)
<kerry> scribe: KJanowic
<kerry> scribenick: KJanowic
patent call [12]https://www.w3.org/2015/spatial/wiki/Patent_Call
[12] https://www.w3.org/2015/spatial/wiki/Patent_Call
kerry: Discussion of how much change we can/should do compared
to OWL:Time
... Dont delete but deprecate
Simon: we are fine as long as we use a new namespace
kerry: Agreed, but this is also about respecting the current
user base
<ahaller2> s/dont/don't
Try to avoid removing parts of the ontology (axioms)
ahaller2: we use a new namespace so we should be fine. The core
will be significantly different but one of the other layers
would be very similar to the existing SSN.
Kerry: fair enough. We have more flexibility than OWL:Time
<ahaller2> +1 for not adding deprecated classes in the core
+1
Sure, I know this
kerry: Agreed but we need to take it back to the group and be
respectful of existing users
Simon: I am pretty sure that this only applies for a previously
published namespace.
... protecting users is done via not making changes to the
existing namespace.
kerry: lets wait for Phil and move on in the agenda
SSN Requirements from UCR
kerry: This is purely a reminder to have a look at UCR and that
we are all happy with the current content.
ISSUE-20 Reference external vocabularies
<kerry> issue-20?
<trackbot> issue-20 -- Reference external vocabularies -- open
<trackbot> [13]http://www.w3.org/2015/spatial/track/issues/20
[13] http://www.w3.org/2015/spatial/track/issues/20
<kerry> ?
kjanowic: isn't this about nomenclature? If so, we should deal
with it
... so this is also about typecasting between class and entity
based classifications, right?
Rob: We also need to look into units of measure
[My daughter just woke up, can somebody please scribe for
2min?]
<kerry> roba: no the issue does not need to stay as it will be
picked up by broader best practice environment although it is
relevant
<kerry> ....whether uom should be part of ssn for example?
<roba> i'll scribe
<kerry> ACTION: frans to close issue-20 please [recorded in
[14]http://www.w3.org/2016/07/12-sdwssn-minutes.html#action01]
[14] http://www.w3.org/2016/07/12-sdwssn-minutes.html#action01]
<trackbot> Created ACTION-184 - Close issue-20 please [on Frans
Knibbe - due 2016-07-19].
<roba> ...pointed out that its a general BP - but a Use Case
and consideration of UoM as a challenge is SSN space
ISSUE-24 clarification of lightweight APIs requirement
<roba> ...kerry - consensus is then the close issue
<kerry> issue-24?
<trackbot> issue-24 -- clarification of lightweight APIs
requirement -- open
<trackbot> [15]http://www.w3.org/2015/spatial/track/issues/24
[15] http://www.w3.org/2015/spatial/track/issues/24
<roba> raul - infrastructure requirement not onotology req.
<roba> armin - agree its infrastructure but points out that
lightweight core will support lightweigt APIs
<roba> kerry - UCR closing - need concrete proposal
[I am back, sorry]
<ahaller2> ahaller-
<roba> Danh - more general problem?
<roba> Kerry - change to an example
Danh: Rephrase this requirement to the lightweight profile of
the ontology wrt IoT.
<RaulGarciaCastro> +1
<roba> roba: req reads like it is intended to ensure SSN is
relevant to the IoT space - but we would need the IoT req
stated
<DanhLePhuoc> +1
<roba> +1
<ahaller2> +1
<kerry> +1
Proposal: Ask Franz to rephrase
+1
<kerry> ACTION: frans to rephrase issue-24 requirement to
something like "develop lightweight profile of the ontology for
IoT" [recorded in
[16]http://www.w3.org/2016/07/12-sdwssn-minutes.html#action02]
[16] http://www.w3.org/2016/07/12-sdwssn-minutes.html#action02]
<trackbot> Created ACTION-185 - Rephrase issue-24 requirement
to something like "develop lightweight profile of the ontology
for iot" [on Frans Knibbe - due 2016-07-19].
Sounds good to me
whether this is about profiles or not is another story that we
can discuss at a later time
Simom: Develop an example how the ontology can be used. The
SOSA Core is not a profile.
Kerry: Show how the ontology can be used for lightweight IOT
needs.
<ahaller2> maybe "require a lightweight way to exchange data
according to the SSN ontology"
see above
<ahaller2> "in the IoT context"
final version: Show how the SSN ontology can be applied in the
context of lightweight IoT needs
Okay>
Okay?
<ahaller2> APIs are always about exchange
<ahaller2> +1
<roba> +1
<DanhLePhuoc> +1
<RaulGarciaCastro> +1
<kerry> ACTION: frans to fix issue-24 by replacing requirment
to "Show how the SSN ontology can be applied in the context of
lightweight IoT needs" [recorded in
[17]http://www.w3.org/2016/07/12-sdwssn-minutes.html#action03]
[17] http://www.w3.org/2016/07/12-sdwssn-minutes.html#action03]
<trackbot> Created ACTION-186 - Fix issue-24 by replacing
requirment to "show how the ssn ontology can be applied in the
context of lightweight iot needs" [on Frans Knibbe - due
2016-07-19].
Suggested changes to ontology editing process/tooling
Ahaller2: We moved the ontology away from Webprotege for may
reasons, one of them being issues with the namespace. This
makes it pretty unusable for our work. Proposal was to use
github.
... Most people will edit the file directly.
We can usue whatever we want as long as we are carful with our
github pull requests and the way we handle the raw file
SOSA/SANDA?
<SimonCox> I find TopBraid generates a very consistent
serialization. It just isn't the same as Protege ...
See:
[18]https://github.com/w3c/sdw/blob/kjanowicz-ssn/ssn/rdf/sosa.
ttl
[18] https://github.com/w3c/sdw/blob/kjanowicz-ssn/ssn/rdf/sosa.ttl
<roba> KJanowic: - didnt get that sorry..
<roba> Kerry: asks for summary
Ahaller2: What we did was taking kjanowic work, add the
actuator class and then change the name and so forth.
ahaller starting the discussion on process and procedure
<SimonCox> Armin + Simon worked on SANDA -
[19]http://webprotege.stanford.edu/#Edit:projectId=32a4ea9e-4d0
6-4f92-8188-07fcd96f81a7
[19]
http://webprotege.stanford.edu/#Edit:projectId=32a4ea9e-4d06-4f92-8188-07fcd96f81a7
<SimonCox> Simon and Jano worked on
[20]https://www.w3.org/2015/spatial/wiki/SOSA_Ontology
[20] https://www.w3.org/2015/spatial/wiki/SOSA_Ontology
<SimonCox> Re Procedure - should be " ... responsible for
generating an observation result or another change in the
world"
<ahaller2> +1 on distinguishing the instruments and the
procedure. This was definitely my intention in the first
proposal of the core
<RaulGarciaCastro> +1
ahaller2, great. But if you look at samplingprocedure and
procedure now, only sampling procedure is about a procedure.
simon: agreed, there is some confusion that we need to clean up
<ahaller2> KJanowic: That was a problem of wrong documentation
of the class.
<ahaller2> KJanowic: Webprotege was playing up with us
<ahaller2> KJanowic: reintroducing rdf:comments for whatever
reason
aheller2: Sure, I just wanted to point this out
same for Results being only created by Sensors (I already
changed this)
Very important issue
<ahaller2> +1 to KJanowic, the procedure is measuring the
temperature of soil or air, depending on how you use the
SensingDevice
<roba> +1 to KJanowic
<RaulGarciaCastro> +1
<SimonCox> ObservingProcedure is subclass of Procedure and
superclass of Sensor?
<ahaller2> SimonCox: we called it Sensing, didn't we
<SimonCox> Procedure is also superclass of ActuatingProcedure
and SamplingProcedure
<SimonCox> ??
Simon: IMHO, the procedure is like to cookbook recipe. It is
not a superclass of sensor.
<SimonCox> Yes - Sensing/Actuating/Sampling better names
<ahaller2> Then yes
<SimonCox> Agree - is recipe, not device
<SimonCox> Uses a device
It is a bridge to workflows
<SimonCox> Agree
Kerry: sorry, yes I will
yes, so if the procedure is a sequence of actions (like in a
receipt) and not a device, than we should change the
description
Rob: There needs to be a method to identify a procedure as well
as to describe it
<ahaller2> +1 to change the description. I think we all are on
the same page
great.
We are also talking about the subtle differences between
sensing and a procedure
Rob: Just needs to be clear to the usage
<kerry> krz: there are instruments, that might be a specific
sensor that
<kerry> ...carries an observation, a sensing is always tking
place..
<kerry> ...but an observation procedure is more of a'to take a
measurement do these steps"
<kerry> ...this is a procedure that makes sure [missed]
<kerry> ...want to be as inclusive as we can e,g instruments
and human sensors
<ahaller2> SensingDevice is an Instrument
<ahaller2> We need to be careful with the Sensor class, this is
why we renamed it to Sensing, because Sensor sounds like a
device
<kerry> .... want to distinguish describing a procedure from
[missed]
<roba> works for me - needs to be front anb centre of
description
If this is okay with everybody, I can do the change in SOSA
(this is all just about the comment, there is no axiom anyway
:-))
<kerry> armin: need to be careful with sensor class which
sounds like an instrument
ahaller2: lets be careful with sensor class as it sounds like
an instrument. sensing is the super class
... we should use sensing
<kerry> ... but sensing is a superclass..., sensor could be
confused with sensing device
Danh: Completely different question: What about the way we are
coding, i.e., RDF versus OWL.
<ahaller2> Sensing would not be the Instrument
<roba> agree
<kerry> krz: sensing implies an action, we need to discuss how
to call this on the email list -- the procedure and the thing
that executes it is doffernt
<ahaller2> SensingDevice is the Instrument
<ahaller2> Human could be the Instrument
In short: there is the procedure and the XYZ that carries out
this procedure to generate a valid observation
<ahaller2> yes
The question is how we call XYZ so that it includes sensors,
simulations, humans,...
kerry closing the meeting
<ahaller2> XYZ could be Sensor, but not sure about the name
<SimonCox> ObservingProcedure?
<SimonCox> EstimatingProcedure?
Summary of Action Items
[NEW] ACTION: frans to close issue-20 please [recorded in
[21]http://www.w3.org/2016/07/12-sdwssn-minutes.html#action01]
[NEW] ACTION: frans to fix issue-24 by replacing requirment to
"Show how the SSN ontology can be applied in the context of
lightweight IoT needs" [recorded in
[22]http://www.w3.org/2016/07/12-sdwssn-minutes.html#action03]
[NEW] ACTION: frans to rephrase issue-24 requirement to
something like "develop lightweight profile of the ontology for
IoT" [recorded in
[23]http://www.w3.org/2016/07/12-sdwssn-minutes.html#action02]
[21] http://www.w3.org/2016/07/12-sdwssn-minutes.html#action01
[22] http://www.w3.org/2016/07/12-sdwssn-minutes.html#action03
[23] http://www.w3.org/2016/07/12-sdwssn-minutes.html#action02
Summary of Resolutions
[End of minutes]
__________________________________________________________
Received on Wednesday, 13 July 2016 15:09:26 UTC