W3C home > Mailing lists > Public > public-sdw-wg@w3.org > January 2017

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)

From: Krzysztof Janowicz <janowicz@ucsb.edu>
Date: Mon, 23 Jan 2017 11:57:27 -0800
To: Joshua Lieberman <jlieberman@tumblingwalls.com>
Cc: Kerry Taylor <kerry.taylor@anu.edu.au>, Rob Atkinson <rob@metalinkage.com.au>, Raúl García Castro <rgarcia@fi.upm.es>, "public-sdw-wg@w3.org" <public-sdw-wg@w3.org>, "Cox, Simon (CESRE, Kensington)" <Simon.Cox@csiro.au>, Armin Haller <armin.haller@anu.edu.au>
Message-ID: <3ee81beb-bd9b-c8a1-9a7f-57b9a5b2e87f@ucsb.edu>
Yes, but it is not mounted or *attached* (that is the term used in the 
SSN definition)  to the platform, it is a program running on a physical 
device. We typically talk about platforms to describe how and where 
multiple sensors are installed on a platform. Running a software on a 
computer is a different scenario. Keep in mind that broadening axioms to 
mean everything implies that they mean nothing which is the opposite of 
what ontologies are supposed to do. But lets for a moment assume that 
the term platform in SSN means absolutely anything we want it to mean, 
even better so, then the argument that SOSA:platform and SSN:platform 
are 'completely different' falls apart entirely.

Best,
Krzysztof



On 01/23/2017 11:50 AM, Joshua Lieberman wrote:
> Not to quibble overly, but a predictive model running on my tablet 
> might qualify as as a virtual sensor on a physical platform.
>
> -Josh
>
>> On Jan 23, 2017, at 2:34 PM, Krzysztof Janowicz <janowicz@ucsb.edu 
>> <mailto:janowicz@ucsb.edu>> wrote:
>>
>> Hi,
>>
>>> Yes SSN platform is a subclass of DUL:PhysicalObject but nothing in 
>>> the old ssn prohibits virtual sensors being mounted on platforms.
>>
>> But mounting a *virtual* sensor to a *physical* platform does not 
>> make any sense. This is like adding virtual tires (e.g., my thoughts 
>> about tires) to a physical car and wondering why it does not move. 
>> Other issue, is this the correct link to our final report of the 
>> SSN:http://www.w3.org/2005/Incubator/ssn/XGR-ssn/?
>>
>>> 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?
>>> Firmly  Agree. I can’t say this strongly  enough.
>>
>> The point here was that we should of course fix the SSN definitions 
>> but that we can either define a relation between the SOSA and SSN 
>> concepts or simply reuse the SOSA concepts for the SSN concepts 
>> whenever needed but that the opposite way does not work because 
>> otherwise SOSA would not be able to work on its own which is the 
>> entire point of SOSA.
>>
>> Best,
>> Krzysztof
>>
>>
>> On 01/23/2017 09:01 AM, Kerry Taylor wrote:
>>> This is a really important conversation. I am glad that it is 
>>> happening at last!
>>> ØGenerally speaking (see also the wiki and the modularization part) 
>>> SOSA concepts should be broader as SSN adds additional axiomatic 
>>> restrictions to these concepts.
>>> Apart from “should be broader” this basic structure  was indeed an 
>>> idea of vertical modularity.  But if this Is the case, then most/all 
>>> SOSA terms need to be superclasses/properties of corresponding SSN 
>>> terms. For SSN to import the core and then to assert its own terms 
>>> as sub-classes of the sosa ones would be very very nasty added 
>>> complexity – exactly the opposite of what we are asked to do in the 
>>> group. So…. Does the relationship between the two ontologies get 
>>> realised as another alignment? In yet another file so as not to 
>>> stuff up either ssn or sosa but to confuse anyone who looks? In 
>>> current form, I don’t believe that a  consistent alignment is even 
>>> possible, nor that this is a good solution even if possible.
>>> On the other hand, a far more simple view would have the core 
>>> introduce  the most used (“core”) concepts of ssn and these are 
>>> imported and further refined in the more complex part of ssn. There 
>>> need be no distinction in meaning at all --- only that the more 
>>> complex ontology axiomatically constrains the meaning wheras the 
>>> simpler core just asserts the mean via rdfs:comment.  That is what I 
>>> have been expecting for the past year. So the core is easy to use, 
>>> and the greater ssn provides depth and extended properties. Easy! 
>>> And no need for equivalence declarations either --- just use exactly 
>>> the same terms and share the namespace! We could have the full ssn 
>>> “import” the core as well (or just reproduce, but I suspect import 
>>> is better). In the full ssn ontology we can add additional 
>>> rdfs:comment properties (or other annotation properties) to expand 
>>> the definition further with reference to other (expanded) ssn 
>>> properties, something like some of the current ssn rdfs:comment 
>>> properties!
>>> Same definitions, but the core is just smaller. I think this is what 
>>> Raul is saying and I*heartily*agree. Simple, consistent, easy to use.
>>> I would add to Raul’s call a further request for same namespace as 
>>> well, as I think this can be done quite cleanly too..
>>> 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?
>>> Firmly  Agree. I can’t say this strongly  enough.
>>>
>>> To contribute to that solution I note:
>>> _(a) Use of rdfs:comment_
>>> (a) the rdfs:comment of the two concepts should be identical. I can 
>>> see no reason why that should not be (following Krzysztof’s argument 
>>> below). However, there should be an identical comment, but full ssn 
>>> could then extend the comment by adding something else that explains 
>>> how it is used in the extended context for extra classes and properties.
>>> (_b) Physical objects_
>>> SSN platform is defined as a subclass of DUL:PhysicalObject.
>>> >>> Thus,
>>> >>>         virtual sensors cannot be mounted on platforms.
>>> Yes SSN platform is a subclass of DUL:PhysicalObject but nothing in 
>>> the old ssn prohibits virtual sensors being mounted on platforms. In 
>>> the meeting last week I think Krzysztof said that dul prohibited it 
>>> via the “attached system” property, and I have checked as I offered. 
>>> Attached system does not constrain platform at all. Attached system 
>>> is an ssn property (defined as “Relation between a Platform and any 
>>> Systems (e.g., Sensors) that are attached to the Platform.”)that is 
>>> a subproperty of dul:islocationOf.
>>> Dul:islocationOf is described as “A generic, relative localization, 
>>> holding between any entities. E.g. 'Rome is the seat of the Pope', 
>>> 'the liver is the location of the tumor'. For 'absolute' locations, 
>>> see SpaceRegion”.  And dul:Entity is pretty much anything.
>>> However, the  ssn:system that attaches is defined as a 
>>> dul:physicalObject and that may be too narrow. I propose changing 
>>> ssn:system to a virtual thing, and leaving Platform as purely 
>>> physical. This  proposed change to system would also repair a 
>>> kind-of  inconsistency in ssn (a ssn:device is a ssn:system but the 
>>> description of device permits it to have components that are 
>>> software, ie not physical objects and so not sub-systems.).
>>> If we need “virtual platforms” – do we? --- then that is easily 
>>> solved by changing the dul subclassing. But this  would make 
>>> ssn:Platform suddenly different from SensorML platform  - do we have 
>>> a use case to support it? I can’t recall one. My objection here is 
>>> in the world of how do we as virtual modellers know whether  to use 
>>> a virtual sensor, a virtual observation, a virtual system  or a 
>>> virtual platform ? I like the idea of platforms being physical (e.g. 
>>> machines) although they may well have “attachedSystem”s that are 
>>> virtual Systems. What is wrong with that? If it is because this is 
>>> too complex for sosa then that is only another good reason to leave 
>>> ssn:platform as it is and to ask sosa users to use ssn for the 
>>> complex case of a system of sensors, whether virtual or otherwise. 
>>> That is an excellent use case for the design of a simple core vs an 
>>> extended more complex model.
>>> _(c)  Restrictions on ssn:platform_
>>> Øthe only axioms left are two forall quantifications on the fillers of
>>> ØattachedSystem and inDeployment. These axioms, however, do notcarry any
>>> Ømeaning as far as platforms are concerned.
>>> Ø…
>>> Ø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
>>> Agreed, well close enough. And this is exactly as it should be – it 
>>> just offers more extended properties available in the full ssn for 
>>> modelling more complex cases.  Strictly, it also tells us that 
>>> something (x) that is in the relation indeployment with something 
>>> (y) where y is not a deployment  implies that x is not a platform.
>>> _(d)  relation to sensorML_
>>> Also, I have not seen my original concern addressed (please see 
>>> issue-88 as first posed):
>>> A ssn:Platform is a well-documented different concept which is 
>>> directly attributed to SensorML's use of the same word (see 
>>> rdfs:comment)
>>> meaning and needs justification. Why are we giving up entirely on 
>>> Sensor ML here without any reason I  can see?No foundation or source 
>>> for the term is noted.One of the strengths of ssn was its documented 
>>>  provenance in pre-existing vocabs, entirely discarded in sosa-core. 
>>> Why does sosa-core discard this?
>>> _(e)  relation to sosa:observation_
>>> As noted in original issue-88 In intent, sosa;platform appears to be 
>>> something like ssn:Device, but, also an alternative to a sensor to 
>>> make an observation (sse rdfs: comment for observation) makes it 
>>> different to a Device, as well.I quote from sosa:observation ”Links 
>>> to a Platform or Sensor to describe what made the Observation and 
>>> how” ,but I can’t see any such ‘link” anyway from observation. Is 
>>> there an  error is on observation rather than platform?
>>> (f) _relation to ssn:device_
>>> And it appears to be something like ssn:Device, (quoting from its 
>>> ssn definition) “A device is a physical piece of technology - a 
>>> system in a box. Devices
>>> may of course be built of smaller devices and software components 
>>> (i.e. systems have components).”A ssn: Device is a ssn:system .  So 
>>> how does sosa:platform relate to a ssn:device?  Note here that a 
>>> ssn:Device is indeed a physical object, not a virtual one, although 
>>> it can have virtual components.
>>> (g_) sosa: hosts property should be “ssn: attachedsystem”?_
>>> an ssn: Platform has an  “ssn:attached system”  that can be a Sensor 
>>> (although, strictly, that  works only for physical sensors as 
>>> actually an attachedsystem must be a System  which a Sensor could be 
>>> asserted to be. We should change systems to be potentially virtual 
>>> see (b) above). So why does SOSA have a “hosts” property for the 
>>> same purpose? What is wrong with “attachedsystem” and its inverse 
>>> “onplatform”?
>>> _(h) comment and question on Sensors and Devices in systems_
>>> __
>>> Devices are systems and systems are assembled from subsystems and 
>>> deployed on platforms. OTOH Sensors are connected to platforms only 
>>> by their subclass, sensingdevice which is both a device (that can be 
>>> onplatform  to a platform and have subsystems) and a sensor.  So is 
>>> a mobile phone a device and all its sensors (e.g.  GPS) sensing 
>>> devices that are subsystems of the mobile phone device? That is, a 
>>> GPS can stand on its own as a sensor (or also as a sensing device) 
>>> but it becomes connected with  the phone by being a subsystem of the 
>>> phone. OTOH, that GPS sensing device (or the mobile phone 
>>> supersystem  for that matter)  can also be attached to a platform 
>>> such as a car.
>>> Then – to for the core (sosa) we could have “sensing devices”  (for 
>>> physical sensors ) optionally as subsystems of some phone or other 
>>> system and also “sensors” for virtual things or just things we are 
>>> not sure about,  and maybe  we just don’t need platforms at all.
>>> If this is all ok—then there are plenty of places where ssn 
>>> rdfs:comments  assume sensors are systems wheras they are not (or at 
>>> least are not defined to be so – they could be asserted to be so in 
>>> any particular usage subject to (b) above) -- and this should be 
>>> repaired. E.g. ssn;platform says “An Entity to which other Entities 
>>> can be attached - particularly Sensors and other Platforms”wheras it 
>>> should be “particularly Systems ”, as it is currently defined 
>>> axiomatically (as all attached systems must be systems and systems 
>>> are physical)..Or, to allow that physical platforms have attached 
>>> systems that can be virtual we can just add to the ontology that a 
>>> sensor is a subclass of a system specifically intended for virtual 
>>> sensor (and subject to (b) above). Alternatively  (better I think) 
>>> allow attachedsystems of Platforms  to be specified to be either 
>>> systems or Sensors or  Platforms. Not sure why we need platforms – 
>>> maybe not platforms.  Or just leave it as is but you would need to 
>>> use a different unnamed property to attach your virtual sensor to a 
>>> platform.
>>> Apologies --- this is much too close to meeting start time to be 
>>> very useful…
>>> Kerry
>>> *From:*Krzysztof Janowicz [mailto:janowicz@ucsb.edu]
>>> *Sent:*Wednesday, 18 January 2017 8:09 AM
>>> *To:*Rob Atkinson<rob@metalinkage.com.au>; Raúl García 
>>> Castro<rgarcia@fi.upm.es>;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,
>>>
>>> Thanks everybody for the fruitful discussion!
>>>
>>> Generally speaking (see also the wiki and the modularization part) 
>>> SOSA concepts should be broader as SSN adds additional axiomatic 
>>> restrictions to these concepts. SOSA can also provide 'semantic 
>>> shortcuts' for more complex axioms in SSN, e.g., in case of property 
>>> paths. Of course, there can also be axioms in SSN that are not in 
>>> SOSA and the other way around (if there is not need for a 
>>> specialization).
>>>
>>>
>>>     We should standardise the concept of Platform, with a single
>>>     meaning for
>>>     everyone.
>>>
>>>
>>> As argued in the in initial email tjhis is currently the case with 
>>> the notable exception that the SSN definition has to be adjusted to 
>>> support virtual sensors.
>>>
>>> Best,
>>> Jano
>>>
>>> On 01/17/2017 12:02 PM, Rob Atkinson wrote:
>>>
>>>     Hi,
>>>     I think the challenge is that you can't introduce the concept in
>>>     a namespace where the complex axioms are included in the same
>>>     artefact (OWL file) - its the conflation in practice of graph
>>>     and namespace - if we are going to decouple these and create
>>>     multiple files using the same namespace but different
>>>     implementations then we need to introduce this practice and
>>>     justify it with examples IMHO. So the simpler idea we are
>>>     following (I thought) would be that SSN would import SOSA, which
>>>     introduces the concepts, and declare equivalence.
>>>     Using the exact same definitions would be critical to being able
>>>     to then point to SSN implementations - so your concerns should
>>>     be accomodated I think. Of course this gets nastier if a SSN
>>>     update in a new namespace is introduced :-)
>>>     Rob
>>>     On Wed, 18 Jan 2017 at 05:21 Raúl García Castro
>>>     <rgarcia@fi.upm.es <mailto:rgarcia@fi.upm.es>> wrote:
>>>
>>>         Hi Krzysztof,
>>>
>>>         I think that we are mixing in the discussion
>>>         conceptualization and
>>>         implementation details.
>>>
>>>         We should standardise the concept of Platform, with a single
>>>         meaning for
>>>         everyone.
>>>
>>>         Then, we will provide two implementations of such concept:
>>>         one with
>>>         lightweight semantics (sosa:Platform) and another one with
>>>         some more
>>>         axioms (ssn:Platform).
>>>
>>>         But the concept itself should be the same; i.e., if some
>>>         system talks
>>>         about a sosa:Platform and another one about an ssn:Platform
>>>         they should
>>>         be referring to the same concept to facilitate interoperability.
>>>
>>>         So, for me the ideal case is that in which both classes are
>>>         equivalent
>>>         (i.e., refer to the same concept) and users are allowed to
>>>         choose
>>>         whether to represent their data with more or less semantic
>>>         commitments.
>>>
>>>         Kind regards,
>>>
>>>         El 17/1/17 a las 17:21, Krzysztof Janowicz escribió:
>>>         > Hi Raul,
>>>         >
>>>         > Both have their own namespaces and the key idea is that
>>>         you can use them
>>>         > independently. From the very beginning we also agreed on
>>>         SOSA having a
>>>         > more lightweight axiomatization wrt the introduced ontological
>>>         > commitments as well as the style of axiomatization, e.g.,
>>>         using
>>>         >schema.org <http://schema.org/>style. So, assuming that we
>>>         do not want that for SSN as well,
>>>         > we should not reuse platform from SSN ind SOSA.
>>>         >
>>>         >> From my understanding, SOSA should be a proper subset of
>>>         SSN, and an
>>>         >> atomic subset also, of course.
>>>         >
>>>         > In an ideal case, SOSA classes should be super classes of
>>>         SSN classes
>>>         > (not the other way around).
>>>         >
>>>         > Best,
>>>         > Krzysztof
>>>         >
>>>         >
>>>         > On 01/17/2017 06:01 AM, Raúl García Castro wrote:
>>>         >> Hi Krzysztof,
>>>         >>
>>>         >> From my understanding, SOSA should be a proper subset of
>>>         SSN, and an
>>>         >> atomic subset also, of course.
>>>         >>
>>>         >> Then, I don't see the problem of having the Platform
>>>         concept in SSN
>>>         >> and also identifying the Platform concept as one of the
>>>         concepts that
>>>         >> are part of SOSA.
>>>         >>
>>>         >> In any case, the Platform concept should have the same
>>>         definition (in
>>>         >> SSN and in SOSA) and should be understandable from both
>>>         perspectives
>>>         >> (SSN and SOSA).
>>>         >>
>>>         >> I don't know why this would not work.
>>>         >>
>>>         >> Kind regards,
>>>         >>
>>>         >> El 17/1/17 a las 11:02, Krzysztof Janowicz escribió:
>>>         >>> Hi Raul,
>>>         >>>
>>>         >>> Thanks for sharing your thoughts. The last alternative,
>>>         namely of having
>>>         >>> a SOSA version does not really work well because this
>>>         would make SOSA
>>>         >>> not atomic anymore in the sense that one would have to
>>>         understand the
>>>         >>> full SSN to use SOSA. SOSA is really just a lightweight
>>>         core for those
>>>         >>> that do not need the full SSN. Btw, I also do not really
>>>         see any issue
>>>         >>> with the first two approaches or disadvantage. We can
>>>         think of the
>>>         >>> axioms als alignments if you like. This would then
>>>         either be a
>>>         >>> subsumption or equivalence alignment. Would that address
>>>         your issue?
>>>         >>>
>>>         >>> Best
>>>         >>> Jano
>>>         >>>
>>>         >>> On Mon, Jan 16, 2017 at 11:03 PM, Raúl García Castro
>>>         <rgarcia@fi.upm.es <mailto:rgarcia@fi.upm.es>
>>>         >>> <mailto:rgarcia@fi.upm.es <mailto:rgarcia@fi.upm.es>>>
>>>         wrote:
>>>         >>>
>>>         >>>     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
>>>         >>> <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
>>>         >>> <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
>>>         <tel:+34%20913%2036%2065%2096><tel:%2B34%2091%20336%2065%2096>
>>>         - Fax: +34
>>>         >>>     91 352 48 19 <tel:%2B34%2091%20352%2048%2019>
>>>         >>>
>>>         >>>
>>>         >>
>>>         >>
>>>         >
>>>         >
>>>
>>>
>>>         --
>>>
>>>         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 <tel:+34%20913%2036%2065%2096>-
>>>         Fax:+34 91 352 48 19 <tel:+34%20913%2052%2048%2019>
>>>
>>> -- 
>>> 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 
>>> <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
>


-- 
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 January 2017 19:58:06 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 January 2017 19:58:07 UTC