Re: SDW meeting this week: approve FPWD for SSN

You're just a neigh-sayer!


On Thu, 26 May 2016 at 09:03 <Simon.Cox@csiro.au> wrote:

> Yeah – racehorses are usually seen going round in circles.
>
> Else they fall over and break.
>
>
>
> *From:* Frans Knibbe [mailto:frans.knibbe@geodan.nl]
> *Sent:* Wednesday, 25 May 2016 6:57 PM
> *To:* Cox, Simon (L&W, Clayton) <Simon.Cox@csiro.au>
> *Cc:* SDW WG Public List <public-sdw-wg@w3.org>
>
>
> *Subject:* Re: SDW meeting this week: approve FPWD for SSN
>
>
>
>
>
>
>
> 2016-05-25 2:21 GMT+02:00 <Simon.Cox@csiro.au>:
>
>
>
> [snip]
>
>  W3C and this joint working group are an opportunity to bridge the divide,
> but does need both sides to appreciate the working methods and constraints
> from the other. In particular, the consensus process sometimes results in a
> camel instead of a racehorse.
>
> :-) That is a nice analogy. At least with the camel we know it will be
> moving in the right direction.
>
>
>
> Regards,
>
> Frans
>
>
>
>
>
> *From:* Frans Knibbe [mailto:frans.knibbe@geodan.nl]
> *Sent:* Tuesday, 24 May 2016 7:02 PM
> *To:* Rob Atkinson <rob@metalinkage.com.au>
> *Cc:* Krzysztof Janowicz <janowicz@ucsb.edu>; SDW WG Public List <
> public-sdw-wg@w3.org>
> *Subject:* Re: SDW meeting this week: approve FPWD for SSN
>
>
>
>
>
>
>
> 2016-05-24 0:47 GMT+02:00 Rob Atkinson <rob@metalinkage.com.au>:
>
>
>
> Possibly very naive take on this, but I feel Frans' pain here :-)
>
>
>
> Apart from a bad knee, which is another matter, I don't feel much pain.
> But I suspect things may be hard for the people looking for an OGC-approved
> standard to work with sensor data. Which to choose? STA and SSN seem to be
> mutually exclusive, although one could use SSN to fill in the things that
> are not specified yet in STA. Also, it could be that SSN will not get the
> attention it deserves on account of it being too intellectual or
> complex-looking, despite the modularization and other efforts to lower the
> threshold for potential users. Requirements for reasoning and inferencing
> might not be already apparant when a choice for a standard is made.
>
>
>
> From a user's perspective it would be great if a choice between the two
> standards does not have to be made, if the STA was based on SSN for
> example. I understand STA can not be changed now, but could a future
> version of the STA data model be an SSN application profile?
>
>
>
> Regards,
>
> Frans
>
>
>
>
>
> Let us consider the "vertical" modularity proposal - as I think it
> potentially helps us untangle and provide a means to help the poor user
> being introduced to this ecosystem:
>
>
>
> Lets each module is itself annotated according to a vocabulary that
> defines its role, something like xx:ontologyType may be (xx:owl-dl,
> xx:registration, xx:schema, xx:serviceProtocols, xx:alignment,
> xx:annotation, xx:proxy=a vocabulary based on another style of spec. )
>
>
>
> Then we can describe the scope of each specification in terms of what it
> does relative to SSN - and SSN can both help resolve the problem, and I
> suspect gain some useful tools to separate concerns.
>
>
>
> obviously xx: is not a SSN domain - but we could put it in OGC as its
> about distinguishing schemas and services - or push it up to W3C. As its
> only annotation, we dont need to make anything depend on it - annotation
> using xx: could be a valid type of vertical module. And we only need two
> note about intention to address scope overlap in the FPWD - one in a scope
> statement at the top and another in the modularisation intent section.
>
>
>
> Has anyone got an existing best practice or counter-proposal that allows
> us to clearly distinguish between the concerns of schema definition,
> inferencing, etc (the xx:* vocab? )
>
>
>
> Rob
>
>
>
>
>
> On Tue, 24 May 2016 at 02:42 Krzysztof Janowicz <janowicz@ucsb.edu> wrote:
>
> Hi,
>
>
>
> SSN specifies similar concepts, plus or minus various constraints on those
> concepts and their relationships. One “could” use HTTP methods to interact
> with resources based on SSN concepts. How to do that has not yet been
> specified in any detail except to the extent that all HTTP REST API’s are
> similar since they are based on HTTP.
>
>
>
> I know what you mean, but just for the sake of being overly picky, the
> Linked Data paradigm defines the interaction in case of the SSN.
>
>
>
> As I mentioned earlier, there is potential for STA extensions to provide a
> service interface for SSN in the future, and it is certainly worthwhile to
> keep that in mind. It’s may also be true that resource models and
> ontologies can look very similar and one may be derived from the other, but
> I don’t think they are the same thing.
>
>
>
>
>
> Agreed.  Resource models and ontologies share some common features but
> they differ greatly. For instance, the formal semantics of ontology
> languages such as OWL is geared towards making inferences and not towards
> modeling constraints.
>
> Best,
> Krzysztof
>
>
>
>
> On 05/23/2016 09:15 AM, Joshua Lieberman wrote:
>
> Frans,
>
>
>
> “Looks like” can be misleading ;>). STA specifies how to interact with
> certain resources using HTTP methods and patterns from OData.  The
> particular resources specified for STA are based on SWE / O&M concepts,
> although it is unknown whether any axioms that might be implied by the STA
> resource model conflict with any defined by omlite.
>
>
>
> SSN specifies similar concepts, plus or minus various constraints on those
> concepts and their relationships. One “could” use HTTP methods to interact
> with resources based on SSN concepts. How to do that has not yet been
> specified in any detail except to the extent that all HTTP REST API’s are
> similar since they are based on HTTP.
>
>
>
> As I mentioned earlier, there is potential for STA extensions to provide a
> service interface for SSN in the future, and it is certainly worthwhile to
> keep that in mind. It’s may also be true that resource models and
> ontologies can look very similar and one may be derived from the other, but
> I don’t think they are the same thing.
>
>
>
> Josh
>
>
>
> On May 23, 2016, at 11:54 AM, Frans Knibbe <frans.knibbe@geodan.nl> wrote:
>
>
>
> Hello Josh,
>
>
>
> Thank you for the information. I do wonder if the distinction between an
> ontology (SSN) and an interface specification (STA) is all that clear. The
> diagram of the datamodel of the SensorThings API
> <http://ogc-iot.github.io/ogc-iot-api/datamodel.html> looks a lot like an
> ontology and defines similar things as SSN does. And since SSN is a web
> ontology, the API that people will use with the st.andards can also be
> similar (HTTP GET, POST, PATCH, DELETE).
>
>
>
> Regards,
>
> Frans
>
>
>
>
>
> 2016-05-23 16:10 GMT+02:00 Joshua Lieberman <jlieberman@tumblingwalls.com
> >:
>
> Frans,
>
>
>
> Some observations and clarifications:
>
>
>
>    - Sensor Things API (STA) is presently an adopted OGC standard.
>    - It is a compatible REST-based profile of existing SWE interface
>    standards, particularly it is also based on the O&M information model.
>    - As a profile, it is compatible with and complementary to existing
>    standards, such as SOS and SPS, not a replacement.
>    - SSN is an ontology, not a service interface specification, so there
>    should not be a direct conflict between SSN and STA, just as there isn’t
>    necessarily conflict between RDF / OWL and Linked Data API or SPARQL API.
>    - To the extent that SSN is / becomes an elaboration of O&M, there is
>    room to make extensions of STA that incorporate the additional concepts and
>    relationships of SSN, such as more elaborate sensor descriptions.
>    - The more direct overlap is probably that between SSN and SensorML
>    and this may require some harmonization work for OGC standards consistency.
>
> Josh
>
>
>
> On May 23, 2016, at 9:58 AM, Frans Knibbe <frans.knibbe@geodan.nl> wrote:
>
>
>
> Hello Kerry,
>
>
>
> A colleague just showed me his work on publishing and consuming sensor
> data. He uses the OGC SensorThings API
> <http://www.opengeospatial.org/projects/groups/sensorthings> and is happy
> with its capabilities and simplicity. I am not sure how far SensorThings
> API is in the process of becoming an official OGC standard, but it is clear
> that there is lots of overlap with SSN. In the introduction of the SSN FPWD
> it says it can be regarded as a modern replacement for OGC's Sensor Web
> Enablement standards. But the same thing can be said about the SensorThings
> API. So questions that come to mind are:
>
>    - Why is the OGC working on development of two standards for the same
>    thing?
>    - If both SSN and the SensorThings API are to become OGC standards, to
>    what extent are they interoperable?
>    - Is there some kind of collaboration between standards developers?
>
> Is it possible to devote some words about other standards that are
> presently in development in the introduction? Perhaps the  W3C Generic
> Sensor API <https://w3c.github.io/sensors/> can also be mentioned?
>
>
>
> Regards,
>
> Frans
>
>
>
> 2016-05-23 8:48 GMT+02:00 Kerry Taylor <kerry.taylor@anu.edu.au>:
>
> Hi all,
>
> As planned, the editors of SSN would like to transition  the current SSN
> editors’ draft (http://w3c.github.io/sdw/ssn/ dated 23 May) to the status
> of “First public working draft” in the w3c and “discussion paper” in OGC.
>
> Please do have a good look before the telecon this week, and do please
> remember that there is nothing final about this – it is much more a
> statement of intent and options  littered with “issues” than a
> specification.
>
>
>
> --Kerry
>
>
>
>
>
>
>
>
>
>
>
> --
>
> Krzysztof Janowicz
>
>
>
> Geography Department, University of California, Santa Barbara
>
> 4830 Ellison Hall, Santa Barbara, CA 93106-4060
>
>
>
> Email: jano@geog.ucsb.edu
>
> Webpage: http://geog.ucsb.edu/~jano/
>
> Semantic Web Journal: http://www.semantic-web-journal.net
>
>
>
>
>