- From: Krzysztof Janowicz <janowicz@ucsb.edu>
- Date: Tue, 17 Jan 2017 13:08:58 -0800
- To: Rob Atkinson <rob@metalinkage.com.au>, Raúl García Castro <rgarcia@fi.upm.es>, public-sdw-wg@w3.org
- Message-ID: <d1e394ec-2886-5d56-1472-1b2580ff7967@ucsb.edu>
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 Webpage: http://geog.ucsb.edu/~jano/ Semantic Web Journal: http://www.semantic-web-journal.net
Received on Tuesday, 17 January 2017 21:09:35 UTC