- From: <Simon.Cox@csiro.au>
- Date: Fri, 5 Feb 2016 02:14:30 +0000
- To: <phila@w3.org>, <public-sdw-wg@w3.org>
I see there was very interesting discussion in the meeting I was unable to attend this week.
Probably the biggest thing that jumps out to me is some clarification of scope of some of the pieces:
Sensor systems
- SSN is primarily about sensor networks. The Sensor-Stimulus-Observation pattern is central, but a bit hard to swallow for many users, so an everyday version is probably required
- In the OGC space, we only have SensorML in this scope area. SensorML was optimised for a very specific task - to support georeferencing of data collected from remote/moving platforms (satellites and planes). It is very flexible, and in principle supports the description of any sensor/platform system, and while it makes some very hard problems tractable, it also makes some easy problems very hard ;)
We are likely dealing with an either-or situation here. Use the one that makes sense for your application - SSN for reasoning over sensor installations and networks and the data generated by these, SensorML for converting low-level data streams to georeferenced 'coverages' (usually imagery).
Observing activities
SSN quite sensibly also included elements of a model for capturing the results of sensing activities. The word 'Observation' is used for records of these. Unfortunately this is subtly different to the way the word was used in the OGC context (where 'Observation' is the activity (occurrent) that generates a result), but close enough (with some semi-equivalent properties) to have caused some confusion. In many applications the confusion doesn't matter - the same information is available. But in semantic applications it probably does.
The observation-is-an-event (usually in the real world) conceptualization is by now embedded quite deep in the Geospatial standards stack. Most obviously in ISO 19156 (which is the ISO version of OGC O&M), but also in the recently published 2nd edition of ISO 19109*, where the observation viewpoint is presented as a complement to the Feature and Coverage viewpoints.
Sampling
Finally, there is a piece of the puzzle which is only promoted to first-class citizen in O&M- sampling. While a sampling strategy is usually implied by a sensing network, it is not called out directly. Experience particularly in the environmental sciences is that sample design is a fundamental aspect of the observational process, and can be considered independently to descriptions of sensors. And as certain spatial/topological patterns (at points, along curves, on surfaces, and in combinations often of lower-dimensional features embedded in higher-dimensional manifolds) are common in a lot of domains/disciplines, there is probably some merit in recognising this and providing a common language for them. (During the analysis and socialization phase of O&M we had discussions with a number of discipline groups, and in many many cases the essential clarification of their information model was achieved by making the sampling-features more explicit.)
Wrap
It looks like Jano and Payam provided some very nice clarifications in the meeting, with Chris also stirring the pot. It is absolutely the case that O&M is a rather simple, high-level model, and leaves plenty of work to be done to turn it into an application**. While O&M was not 'born semantic' we've done some work recently to remedy that and at least have an ontology version that can used for comparison. O&M is completely silent on the issues that are the main topic of SSN (sensing and sensors). But O&M has also had widespread deployment in real systems, so it appears to be 'just enough' for a lot of applications in the wild. In particular, O&M provides the query signature, and response payload, for OGC Sensor Observation Services. The recent appearance of a JSON version saw immediate adoption in a serious system (hosted by the Irish Marine Institute) so there is an itch to be scratched there too.
In the context of the OGC SWE initiative O&M was conceived as a more user-centric (or at least discovery-centric) view of sensor data then SensorML which is very provider centric. These different views are used quite naturally in different applications, or perhaps at different phases of a data discovery and processing exercise. I suspect that a similar factoring of concerns could be helpful in the modularization being considered for SSN.
By now this has taken longer to write than the length of the telecon that I missed. I hope it helps us move forward.
Simon
Footnotes
*ISO 19109 is called 'Rules for Application Schema', and is one of the more fundamental of the ISO 19100 series, as it defines a meta-model for geographic applications, based around typed features, their properties - some of which vary within the scope of a feature (i.e. coverages), and the assignment of property values - with 'observation' being one specialization of the "property-value-assignment" class. One view of Observations is that their description provides property-value-metadata, which in a sense ties back to Jano's record-oriented conceptualization.
** At the very least an application must provide instances of the classes Process*** (which is the placeholder for sensor, algorithm, observer), GF_PropertyType (aka attribute, parameter, observable property, measurand, variable), GF_Feature (the feature of interest, usually typed) to fill-in-the-blanks.
***In this case I confess that O&M made the wrong decision, which has led to some other confusion. I should have done my homework here. O&M Process is the agent involved in the observation, which might be a sensor or sensor-system, typically reusable - a continuant. I took a lead from SensorML here, and harmonization of terminology was considered desirable at the time. But the term Process is more often used in the broader community for an occurrent.
-----Original Message-----
From: Phil Archer [mailto:phila@w3.org]
Sent: Thursday, 4 February 2016 8:05 AM
To: SDW WG Public List <public-sdw-wg@w3.org>
Subject: [Minutes] 2016-02-03
As ever, the minutes of today's meeting are at https://www.w3.org/2016/02/03-sdw-minutes
The black and white version is provided below.
Spatial Data on the Web Working Group Teleconference
03 Feb 2016
[2]Agenda
[2] https://www.w3.org/2015/spatial/wiki/Meetings:Telecon20160203
See also: [3]IRC log
[3] http://www.w3.org/2016/02/03-sdw-irc
Attendees
Present
eparsons, Linda, ScottSimmons, RaulGarciaCastro,
BartvanLeeuwen, frans, Lewis_John_McGibbney,
ChrisLittle, ClausStadler, Payam, DanhLePhuoc, ahaller2,
robin, MattPerry, phila
Regrets
Kerry, Simon, Jeremy, Lars, Clemens, Bill, Andrea,
Andreas, Josh
Chair
eparsons
Scribe
linda
Contents
* [4]Topics
1. [5]F2F homework for next week
__________________________________________________________
<Lewis_John_McGibbney> Afternoon Folks,
<Lewis_John_McGibbney> Can someone PM me the Webex login?
<Lewis_John_McGibbney> Than kyou
<eparsons> Hello Lewis_John_McGibbney
<eparsons> It's the topic..
<Lewis_John_McGibbney> Grand
<eparsons> scribe: linda
<ChrisLittle> +1 to Linda
<frans> thank you Linda
eparsons: may not be a full length call
<eparsons> Topic : Approve last week's minutes
<eparsons> Proposed : Approve last week's minutes
<eparsons> [6]http://www.w3.org/2016/01/27-sdw-minutes
http://www.w3.org/2016/01/27-sdw-minutes
+1
<Lewis_John_McGibbney> +1
<RaulGarciaCastro> +1
<ScottSimmons> +1
<frans> +1
<ClausStadler> +1
<DanhLePhuoc> +1
<ahaller2> +1
<BartvanLeeuwen> +1
<eparsons> Resolved : Approve last week's minutes
<ChrisLittle> 0 not oresent
<eparsons> Topic : Patent Call
<robin_> +1
<eparsons> [7]https://www.w3.org/2015/spatial/wiki/Patent_Call
[7] https://www.w3.org/2015/spatial/wiki/Patent_Call
<eparsons> Topic : FYI Joint call with DWBP 17th February
eparsons: the next call after the f2f will be a joint call with
the data on the web best practice group
... to deal with items in coordination with this group
... particularly the editors
... may prepare this in the f2f next week
<eparsons> Topic : Review of SSN wiki pages
<frans> good idea to link up!
eparsons: Kerry has asked us to do this
<eparsons>
[8]https://www.w3.org/2015/spatial/wiki/SSN_Wish_List
[8] https://www.w3.org/2015/spatial/wiki/SSN_Wish_List
<frans> I am interested in SSN, to learn some more about the
subject
eparsons: this is a link to a brain dump by Kerry about the
thing she expects to be part of the ssn deliverable
... lets work through this list and see if anything's missing
<Payam> +1
eparsons: anyone closer to the topic who wants to walk us
through these?
<Payam> +q
<frans> Has anyone ever used SSN?
Payam: i was involved in ssn work
<KJanowicz> I was involved as well
Payam: one of the key issues was the modularity of the
ontology.
... we started creating modules, Simon knows a lot about this
... became a complex model
... we omitted multilanguage support
<frans> Will the idea of SSN being an upper ontology remain
intact?
Payam: another thing we didn't do was create tools or libraries
to transform CSV to SSN
eparsons: KJanowicz has a comment
KJanowicz: may jump in if I have comments
Payam: ssn became popular but tools are lacking
KJanowicz: originally semantic sensor network ontology, but
also went into observation part.
... but missing is unit and type of measurement values
Payam: correct
... the next item: probably actuation is meant. This is not
supported by ssn but is requested. A group may have tried to do
this.
... network structure: not clear what kerry means here
... ssn structure is device oriented, we never looked at human
sensory data
KJanowicz: ssn supports human sensors, but explicitly excludes
this in the definition
<Payam> correct
eparsons: can you clarify?
KJanowicz: for example, if I say it is raining, this is an
observation
<frans> So this is about humans using their own senses? Not
humans carrying devices?
eparsons: seems like a broader scope then. Any data/observation
collected by any actor.
ChrisLittle: I think it's good to have activation and
actuation.
<frans> Current definition of sensor seems not to exclude human
senses:
[9]https://www.w3.org/2005/Incubator/ssn/ssnx/ssn#Sensor
[9] https://www.w3.org/2005/Incubator/ssn/ssnx/ssn#Sensor
ChrisLittle: and about human observations: there are frameworks
in which this can be very reliable information
... so am in favor of them being in scope
... and ogc standards support this, this could plug the gap in
ssn
KJanowicz: output of computer models can also be called
observations
[missed a bit]
ahaller2: important to tackle this
... about the values: important to work together with the csv
on the web WG.
<KJanowicz> +1
ahaller2: they also have a JSON encoding
<Payam> ahaller2: it is important to work on actuation- WoT
group also finds this important
eparsons: good point. There is much more interest in this from
a broader community now.
ChrisLittle: csv for transmitting observations leads me to
think about the difference between precision and accuracy which
is sometimes ignored. Don't know how ssn addresses that.
eparsons: broader than just ssn, would be good to have
pointers.
<frans> Precision and accuracy should be addressed in the data
on the web context, I think
Payam: systems platforms and deployment: details of this are
not included in ssn
... e.g. what are the details of systems that should be
specified?
... in ssn this is not specified, only some examples.
... validation: we have a validation tool but this could be
made more formal.
... like HTML validators etc.
... ssn doesn't have a descriptive model for how to describe
location.
... if sensing resources are mobile, it is unclear how to
specifiy this
... ssn has some examples, but they are fragmented and not
detailed.
... uncertainty: there is nothing in ssn to deal with trust,
quality etc.
... IoT light might become a note; the idea is to have a simple
version, ssn light, a compact version that would be useful to
web of things WG.
... stories: linking to best practices, examples of where ssn
is adopted.
... Ontology classes are described etc, but there is no How to
get started with SSN tutorial. This would be helpful.
... Also nothing about reasoning with ssn. Examples would be
useful.
... At the moment ssn is specified in RDF, it would be good to
see if it can be specified in JSON(LD?)
... Also, looking at provenance.
KJanowicz: ssn emerged on the linked data side. Viewed as
records, while OGC views the values as events.
... If we take Dolce away my proposal would be not to talk
about events at all.
Payam: sampling features
KJanowicz: in ssn there is not much about sampling strategies.
Payam: that's it
eparsons: any comments anyone?
... or a question: how realistic is delivering 70% of those
wishes?
<Payam> +q
eparsons: seems to me like we need to prioritize them. And do
some scoping.
KJanowicz: unrealistic, we should focus on ssn light
<Payam> agree- focusing on SSN-lite is a good idea
eparsons: do you have a particular community in mind that would
need ssn light?
<Payam> +q
<ahaller2> +1 for SSN-Lite
<DanhLePhuoc> +q
KJanowicz: e.g. big repositories of earth obeservation data,
domain models
BartvanLeeuwen: last time i wondered why this is on our
charter. It's really a lot.
... we could say something about how you would encode location,
this is close to our SDW BP work
<eparsons> evening phil
frans: we have a task force for ssn, what about bringing in
outside people to help work on this?
... we are open to collaboration, right?
eparsons: even with collaborators it's a lot of work. We should
focus on the spatial aspects. But collaboration would
absolutely be a good idea.
<KJanowicz> we have a lot of expertise about SSN in this group
ChrisLittle: guidance of what should be in ssn or not would be
good - in relation to o&m.
... where's the overlap and what does ssn do that o&m doesn't?
<KJanowicz> E.g., o&m is not about sensor networks
eparsons: good point, could you add this to the wiki?
<Payam> O&M is be also complex at times to describe the data;
isn't also described in XML?
there's a proposed json encoding just out, Payam
<KJanowicz> o&m as such can also not directly used for
semantically enabled Linked Data but there is a version from
SCox that does.
Payam: ssn is popular, if we could create a working model for
data in ssn, this would increase the impact.
<Lewis_John_McGibbney> I need to drop off early today folks.
Thanks for the insight into SSN. I am still lacking context but
this has helped a lot. I look forward to seeing more of this
topic on list.
Payam: e.g. location specification and measurement data and
make it modular and extensible
<eparsons> action ChrisLittle to add to wiki SSN vs. O&M
illustration
<trackbot> Created ACTION-134 - Add to wiki ssn vs. o&m
illustration [on Chris Little - due 2016-02-10].
DanhLePhuoc: I'm currently in Web of THings WG. We have a lot
of industry parties that have sensor devices.
... they want interoperability and ssn is a candidate.
... problem is ssn is to big, ssn-lite is needed
... good modular version would be adopted 6 months ago
... internet of things needs spatial data
<Payam> +q
eparsons: for ssn-lite we would need to identify clearly what
the target community is.
KJanowicz: ssn is broader than o&m. The latter is not about
sensor network etc.
... secondly, a lot of data does not require a lot of detail,
often not entire ssn is needed, only a metadata record about
the instrument, eg in oceanography.
... ssn lite would rule here too
Payam: ssn can now not be used for annotating data
<KJanowicz> I could not hear Payam
ChrisLittle: I may be misunderstanding but there are a lot of
standards on top of o&m that allow you to describe networks etc
... thats why scoping ssn is important
<KJanowicz> There is a lot of voice
<KJanowicz> noise
ChrisLittle: in metereology and oceanography etc there are a
lot of ontologies existing. A lot of work done.
<eparsons> KJanowicz can you 1:1 with Payam
<Payam> I said that SSN specifies abstract concepts and their
relations; SSN-Lite should help to create SSN instances to
describe sensors/data
thanks payam
<frans> Thanks, the SSN information was educational.
eparsons: thanks for this useful discussion and ideas.
<KJanowicz> ChrisLittle: yes, see
[10]http://schema.geolink.org/
[10] http://schema.geolink.org/
F2F homework for next week
eparsons: one of the requirements is to continue work on the
BP. For that we need examples!
... Bring examples to the f2f that can fit into the BP. There
are slots for them already in the BP.
... Examples should be on the web; with a description why it is
a best practice.
... Really helpful if we can get plenty of these.
<Payam> +q
phila: Can you prioritise? Try to match best practices with
specific persons?
frans: can we bring examples of not so good practices?
<KJanowicz> +1 for the anti-patterns
<ScottSimmons> must leave early, bye
eparsons: absolutely
<ChrisLittle> +1 to bad practice
Payam: We editors discussed this. If someone has a model
example, we can discuss this and gain concensus on how to
specify the examples.
... during the meeting we can then assign tasks to specific
persons.
eparsons: what mechanism?
Payam: email list
... we need to have 1 or 2 to start with, so we can decide what
the form should be.
eparsons: anyone who can contribute one before next week?
BartvanLeeuwen: as narrative or as something I can show?
<Payam> +q
eparsons: not a huge narrative, something you can point at and
a sentence describing it would be good
BartvanLeeuwen: will see what I can do
<eparsons> Topic : CEO-LD Report
<phila> [11]CEO-LD Project
[11] https://www.w3.org/2015/ceo-ld
<eparsons> action BartvanLeeuwen Email Public List with example
of BP as an initial example for F2F
<trackbot> Error finding 'BartvanLeeuwen'. You can review and
register nicknames at
<[12]http://www.w3.org/2015/spatial/track/users>.
[12] http://www.w3.org/2015/spatial/track/users
phila: project funded by british embassy in Beijing. It's a
specifically UK thing.
... idea is that they will contribute to Coverage work of this
WG
... everyone involved in CEO-LD group is involved in this group
as well.
... next meeting Sunday 28th february. Nothing has been done
since September.
... Jon Blower has done cool work regarding this
<phila> [13]Coverage Data REST API Core Specification
[13]
https://github.com/Reading-eScience-Centre/coverage-restapi/blob/master/spec.md
phila: covers things we will be concerned about in this group
when we work on this
... eg subsetting, how webby is it, etc
... if you're interested in coverages, look at this work
... see the Melodies project for this
<eparsons> 2 minute warning !!!
phila: chunks of this work could be useful also for our BP
... talks about JSON, content negotiation, and other stuff we
could find useful. Thanks to Jeremy for pointing this out.
<phila> [14]Mailing list
[14] https://lists.w3.org/Archives/Public/public-ceo-ld/2016Feb
phila: project is open to anyone to join the mailing list
<BartvanLeeuwen> see you next week !
<phila> Linda++
KJanowicz: [missed that last bit]
<KJanowicz> +1 for Linda
<ChrisLittle> bye and thanks to Linda
<KJanowicz> bye bye
<Payam> thanks and bye
eparsons: thanks everyone!
<eparsons> bye !!
bye!
<frans> bye!
[End of minutes]
__________________________________________________________
Received on Friday, 5 February 2016 02:16:04 UTC