- From: Maxime Lefrançois via GitHub <sysbot+gh@w3.org>
- Date: Thu, 29 Mar 2018 13:43:49 +0000
- To: public-sdwig@w3.org
Hi, Thanks for this remarks. We did not reach a consensus on whether or not such a property had to be defined, so this is left for a potential future version of the SSN ontology. This is not planned at the moment. It can only be done by a new Working Group with a charter that state a new version of the SSN ontology will be published as a recommendation --> 2 years process. In the meantime, at the URL of the sensor, nothing prevents you from providing information about its super-system. Example: ``` REQ: GET sensor/123 RES: 200 OK Content-Type: text/turtle @prefix ssn: <http://www.w3.org/ns/sosa/>. @prefix ssn: <http://www.w3.org/ns/ssn/>. @base <> <http://example.org/>. <sensor/123> a sosa:Sensor . <system1> ssn:hasSubSystem <sensor/123> . ``` You can of course create your own extension of SSN and define an inverse property for `ssn:hasSubSystem`. As for the distinction between `ssn:hasSubSystem` and a `sosa:hosts`, you can use one or both, depending on what you need. I explained (my understanding of) the distinction between the two concepts in a paper submitted at ESWC this year (rejected unfortunately, but openly accessible online). Maybe this can help https://2018.eswc-conferences.org/paper_196/ See p. 10 and 11, section p. 4.1, paragraph *Smart-Sensors Composition*. -- GitHub Notification of comment by maximelefrancois86 Please view or discuss this issue at https://github.com/w3c/sdw/issues/1022#issuecomment-377239353 using your GitHub account
Received on Thursday, 29 March 2018 13:43:52 UTC