- From: Krzysztof Janowicz <janowicz@ucsb.edu>
- Date: Mon, 23 May 2016 16:01:16 -0700
- To: Rob Atkinson <rob@metalinkage.com.au>, public-sdw-wg@w3.org
- Message-ID: <57438BBC.4020703@ucsb.edu>
> > 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 Webpage: http://geog.ucsb.edu/~jano/ Semantic Web Journal: http://www.semantic-web-journal.net
Received on Monday, 23 May 2016 23:01:47 UTC