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)

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

-----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 08:29:06 UTC