- From: Armin Haller <armin.haller@anu.edu.au>
- Date: Tue, 24 Jan 2017 00:46:21 +0000
- To: Kerry Taylor <kerry.taylor@anu.edu.au>, "janowicz@ucsb.edu" <janowicz@ucsb.edu>, Joshua Lieberman <jlieberman@tumblingwalls.com>
- CC: 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>
- Message-ID: <437C2D34-6FD9-4D6A-BE1A-F482F179A331@anu.edu.au>
I can see rapid convergence here in this thread. Everyone seems to agree that virtual things can be platforms and/or systems and that they have always been and that the rdfs:comment for Platform in SSN new and SOSA should be the same. Let’s just make sure we include this virtual things in the rdfs:comment. Also, we do not have a System class in SOSA for simplicity reasons, as we all agree, SOSA should be simpler than SSN new and avoid some property chains. Of course SOSA would use a different namespace, so even if the rdfs:comment is the same, sosa would use sosa:Platform and not ssn:Platform, but as everyone agrees they should be the same thing. I have included Krzysztof’s proposal for the rdfs:comment for both in the agenda. Please do look at the https://www.w3.org/2015/spatial/wiki/Mapping_Table<https://www.w3.org/2015/spatial/wiki/Mapping_Table)> wiki and make edits to that definition if you feel needed and we can discuss the rdfs:comment in the call and close this fairly simple issue. From: Kerry Taylor <kerry.taylor@anu.edu.au> Date: Tuesday, 24 January 2017 at 11:18 am To: "janowicz@ucsb.edu" <janowicz@ucsb.edu>, Joshua Lieberman <jlieberman@tumblingwalls.com> Cc: 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> 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) The key element of a ssn:platform is its relationship to sensors. Remember this arises from SensorML where they are also physical and was introduced there for the same reason it occurs in ssn. Personally, I see no problem with software being “attached” to a computer --- but if we are super keen that platforms can be virtual (again, why are we keen?) then let us make them so. No problem. But it is absurd that a sosa:platform is somehow a virtual thing and ssn:platform somehow is not. They MUST be the same. Furthermore they both should be called the same thing i.e. ssn:platform. -Kerry From: Krzysztof Janowicz [mailto:janowicz@ucsb.edu] Sent: Tuesday, 24 January 2017 6:57 AM 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; Cox, Simon (CESRE, Kensington) <Simon.Cox@csiro.au>; Armin Haller <armin.haller@anu.edu.au> 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) 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><mailto:rob@metalinkage.com.au>; Raúl García Castro <rgarcia@fi.upm.es><mailto:rgarcia@fi.upm.es>; public-sdw-wg@w3.org<mailto: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<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<mailto:jano@geog.ucsb.edu> Webpage: http://geog.ucsb.edu/~jano/ Semantic Web Journal: http://www.semantic-web-journal.net
Received on Tuesday, 24 January 2017 00:47:05 UTC