- From: Raúl García Castro <rgarcia@fi.upm.es>
- Date: Tue, 17 Jan 2017 10:15:51 +0100
- To: Simon.Cox@csiro.au, public-sdw-wg@w3.org
El 17/1/17 a las 9:28, Simon.Cox@csiro.au escribió: >> I don't like either the alternative of removing ssn:Platform, because we stop providing support to existing implementations > > What is precisely the issue here? > Is it that sosa:Platform would have a different URI than SSN:Platform ? > If so, then it should be noted that ssn:Platform would also be different to SSN:Platform, since a new namespace is being introduced. So there is a mapping from the new URIs to the ones used in existing implementations anyway. > > @prefix SSN: http://purl.oclc.org/NET/ssnx/ssn# . > @prefix ssn: http://www.w3.org/ns/ssn/ . Hi Simon, I think that the problem is not related to URIs. In any decision that we take, we will be able to implement it satisfactorily. My view is that if we are providing an updated version of SSN and we are updating the definition of a concept already existing in SSN (such as Platform), then the expected behaviour is that the new concept is in ssn. Then, any person implementing SSN just has to check whether ssn is good for them and, if so, they have just to replace SSN with ssn in their ontology and they are updated to the second version of the ontology. If the definition of such concept disappears from SSN and appears under a new namespace, we are asking people to spend more effort both to understand the new version and to update their implementations. Maybe it is not so much a matter of stop providing support but of facilitating adoption/migration. Kind regards, > -----Original Message----- > From: Raúl García Castro [mailto:rgarcia@fi.upm.es] > Sent: Tuesday, 17 January, 2017 18:03 > To: public-sdw-wg@w3.org > Subject: Re: ACTION-251: (ISSUE-88) write up how an ssn:platform and a sosa:platform are essentially the same, with an example (Spatial Data on the Web Working Group) > > Hi Krzysztof, > > I don't like either the alternative of removing ssn:Platform, because we stop providing support to existing implementations, or the one of having two *:Platform, because we hinder adoption of the specification (making it more difficult to understand) and interoperability (having multiple systems with non-equivalent platforms). > > I would go for a 3rd option: if the definition of ssn:Platform has some issues, what has to be updated in the definition of ssn:Platform in order for such issues to be solved? > > The required updates will surely make both views of Platform equivalent and then we will be just using a single "platform concept" across the specification. > > Kind regards, > > El 17/1/17 a las 4:34, Krzysztof Janowicz escribió: >> Hi, >> >> This message discusses the relation between ssn:platform and >> sosa:platform. An argument was made that both are 'completely different' >> and cannot be aligned. This message will show that this is not the >> case and that both concepts are indeed conceptually very similar. In >> fact, the ssn:platform is problematic and ill-defined. In the >> following SSN will refer to the 'old' SSN, not necessarily the currently revised version. >> >> Let us start by looking at the textual definitions/descriptions. >> >> According to SOSA, a platform is defined as "[a] device, >> (computational) system, or agent (including humans). A platform >> carries at least one sensor, actuator, or sampling device to produce >> observations, actuations, or samples, by following a procedure. In >> case of virtual sensors, a platform can be a computing system which >> hosts software implementations, e.g., simulations." >> >> According to SSN, a platform is "An entity to which other entities >> can be attached - particuarly [sic] sensors and other platforms. For >> example, a post might act as a platform, a buoy might act as a >> platform, or a fish might act as a platform for an attached sensor." >> >> The key characteristic of a platform in both SOSA and SSN is that it >> carries something, e.g., a sensor, actuator, or another platform. The >> SOSA definitions states more explicitly what is carried while the old >> SSN definition is broader in the sense that any 'entity' to which >> other entities can be attached constitutes a platform (e.g., a wall >> hook is a platform as one can attach a picture to it). From a formal >> perspective, however, there is no difference here, e.g., an SSN >> platform can carry an actuator and a SOSA platform can carry a >> platform. We can make this more explicit in the SOSA platform >> definition if this would help to remove confusion. >> >> Both SOSA and SSN explicitly include agents such as fish or humans as >> platforms for sensors such as their eyes. This is another part where >> the definitions are well aligned. The SOSA definitions explicitly >> mentions devices and so forth, as it has fewer axioms and thus relies >> more on textual descriptions to convey meaning. Also, SSN does not >> deal with sampling, so understandably the SOSA definitions mentions >> sampling devices while the SSN definition does not. >> >> Most importantly, SOSA explicitly lists virtual sensors in the >> platform definition while SSN does not. In both cases, the developers >> of SOSA and SSN have explicitly stated that they support virtual >> sensors. SOSA is simply more consistent in doing so as SSN has been >> repeatedly criticized for an uneven handling of virtual sensors; more details below. >> >> >> More formally speaking: >> >> SSN platform is defined as a subclass of DUL:PhysicalObject. Thus, >> virtual sensors cannot be mounted on platforms. If I remember >> correctly, it was Claus who provided the nice example of the >> simulation of self-driving cars in which the positioning of the >> virtual sensors is key. SOSA would support such scenario, while the old SSN would not. >> Clearly, this had to be changed. >> >> The new SSN does not have a DUL alignment anymore and thus the only >> axioms left are two forall quantifications on the fillers of >> attachedSystem and inDeployment. These axioms, however, do not carry >> any meaning as far as platforms are concerned. This is a similar >> situation to the recent subsystems discussion. I explained in said >> discussion why removing the existential restriction is problematic and >> the same problem appears for SSN platform. Simply put platform(x) AND >> inDeployment(x,y) >> --> deployment(y). In other terms, the two axioms tell us something >> about systems and deployments but not about platforms. Long story >> short, there is no real formal definition left (after removing DUL) >> and thus really anything can be an ssn:platform. Consequently, all >> SOSA platforms can be SSN platforms. By design (roughly (!)) the same >> can be said about platform in SOSA. Thus, the claim that the two >> definitions would be in any way incompatible or not align-able is wrong. >> >> >> Recommendation: I like to think of SOSA as being to the new SSN what >> SSO was to the old SSN and not as some sort of entirely separate >> entity. I do not see any need for a ssn:platform in the new SSN and >> would propose using the platform class from SOSA instead. >> Alternatively, one could define ssn:platform as a subclass or >> sosa:platform if there would be any specific reason to distinguish both. >> >> >> Best, >> Krzysztof >> >> >> On 01/11/2017 04:01 AM, Spatial Data on the Web Working Group Issue >> Tracker wrote: >>> ACTION-251: write up how an ssn:platform and a sosa:platform are >>> essentially the same, with an example (Spatial Data on the Web >>> Working Group) >>> >>> http://www.w3.org/2015/spatial/track/actions/251 >>> >>> On: Krzysztof Janowicz >>> Due: 2017-01-18 >>> Issue: ISSUE-88 (Why is a sosa-core platofrm completely different to >>> an ssn:platform?)Product: Semantic Sensor Network Ontology >>> >>> If you do not want to be notified on new action items for this group, >>> please update your settings at: >>> http://www.w3.org/2015/spatial/track/users/43518#settings >>> >> >> > > -- Dr. Raúl García Castro http://www.garcia-castro.com/ Ontology Engineering Group Departamento de Inteligencia Artificial Escuela Técnica Superior de Ingenieros Informáticos Universidad Politécnica de Madrid Campus de Montegancedo, s/n - Boadilla del Monte - 28660 Madrid Phone: +34 91 336 65 96 - Fax: +34 91 352 48 19
Received on Tuesday, 17 January 2017 09:16:28 UTC