- 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