Re: SDW meeting this week: approve FPWD for SSN

Possibly very naive take on this, but I feel Frans' pain here :-)

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