RE: SDW meeting this week: approve FPWD for SSN from Simon.Cox@csiro.au on 2016-05-24 (public-sdw-wg@w3.org from May 2016)

From: <Simon.Cox@csiro.au>
Date: Tue, 24 May 2016 00:25:05 +0000
To: <rob@metalinkage.com.au>, <janowicz@ucsb.edu>, <public-sdw-wg@w3.org>
Message-ID: <f3cad1e7a9b04b7fbb9070215be7a117@exch1-mel.nexus.csiro.au>
SHACL has had a rather tough gestation.
There were two camps involved – one which probably would have just stuck with RDFS/OWL and SPARQL/SPIN (let’s call them ‘the pragmatists), and the other who refused to contemplate using RDFS/OWL structures in a closed-world sense, ever, anywhere (the purists). That is a gross simplification of course, but you can probably get the drift. So SHACL emerged as a kind of ‘shadow’ schema language, saying many of the same things as RDFS/OWL, but explicitly closed world.

Primary applications are

(i)                 Validation

(ii)               Form building.

Simon

From: Rob Atkinson [mailto:rob@metalinkage.com.au]
Sent: Tuesday, 24 May 2016 9:45 AM
To: janowicz@ucsb.edu; Rob Atkinson <rob@metalinkage.com.au>; public-sdw-wg@w3.org
Subject: Re: SDW meeting this week: approve FPWD for SSN

SHACL seems to be a way to handle the multiple schemas for a single set of concepts part of it - if I read it right - which IMHO confirms that this is a concern that needs specific treatment.

Its not that obvious to me how it relates to the OWL-DL expressivity issue however - does one use SHACL over the top of an OWL-DL model to add extra constraints for certain cases without breaking the model? AFAICT its scope excludes how  the specifcations of services and operations get bound to the model.?

The BP scope will need to include a primer on how these approaches relate to each other I feel. I think the likelihood of a consumer of a BP document being an expert in each and every such specification is close to nil, so the BP needs to be a guide,

Rob





On Tue, 24 May 2016 at 09:01 Krzysztof Janowicz <janowicz@ucsb.edu<mailto:janowicz@ucsb.edu>> wrote:

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

I guess some of this will have to wait until SHACL is released:
http://w3c.github.io/data-shapes/shacl/


Jano


On 05/23/2016 03:47 PM, Rob Atkinson wrote:

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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto:jano@geog.ucsb.edu>

Webpage: http://geog.ucsb.edu/~jano/<http://geog.ucsb.edu/%7Ejano/>

Semantic Web Journal: http://www.semantic-web-journal.net





--

Krzysztof Janowicz



Geography Department, University of California, Santa Barbara

4830 Ellison Hall, Santa Barbara, CA 93106-4060



Email: jano@geog.ucsb.edu<mailto:jano@geog.ucsb.edu>

Webpage: http://geog.ucsb.edu/~jano/


Semantic Web Journal: http://www.semantic-web-journal.net
Received on Tuesday, 24 May 2016 00:25:51 UTC