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 07:03:53 UTC