- From: Krzysztof Janowicz <janowicz@ucsb.edu>
- Date: Tue, 7 Feb 2017 14:17:28 -0800
- To: Rob Atkinson <rob@metalinkage.com.au>, Armin Haller <armin.haller@anu.edu.au>, Kerry Taylor <kerry.taylor@anu.edu.au>, "public-sdw-wg@w3.org" <public-sdw-wg@w3.org>, "Simon.Cox@csiro.au" <Simon.Cox@csiro.au>, Maxime Lefrançois <maxime.lefrancois@emse.fr>
- Message-ID: <f644639b-1b6e-6ae2-ebcf-f67d0b55d116@ucsb.edu>
Hi Rob, > Equivalence axioms would be required to use the legacy SSN, and these > can handle name changes. Do you mean equivalence relations between old-SSN and new-SSN? Jano On 02/07/2017 01:09 PM, Rob Atkinson wrote: > NB If the ssn namespace is updated, then the backwards compatibility > issue here is spurious AFAICT > Equivalence axioms would be required to use the legacy SSN, and these > can handle name changes. > > > On Wed, 8 Feb 2017 at 07:48 Armin Haller <armin.haller@anu.edu.au > <mailto:armin.haller@anu.edu.au>> wrote: > > This is a compromise I thought we were heading to yesterday. > > +1 from me for this approach on solving the observable property issue. > > *From: *Kerry Taylor <kerry.taylor@anu.edu.au > <mailto:kerry.taylor@anu.edu.au>> > *Date: *Wednesday, 8 February 2017 at 1:54 am > *To: *Rob Atkinson <rob@metalinkage.com.au > <mailto:rob@metalinkage.com.au>>, "public-sdw-wg@w3.org > <mailto:public-sdw-wg@w3.org>" <public-sdw-wg@w3.org > <mailto:public-sdw-wg@w3.org>>, "Simon.Cox@csiro.au" > <Simon.Cox@csiro.au>, Maxime Lefrançois <maxime.lefrancois@emse.fr > <mailto:maxime.lefrancois@emse.fr>> > *Subject: *RE: Proposals (was Re: Architecture of SOSA/SSN > integration) : issue-87 only: FIRM PROPOSAL > *Resent-From: *<public-sdw-wg@w3.org <mailto:public-sdw-wg@w3.org>> > *Resent-Date: *Wednesday, 8 February 2017 at 1:55 am > > Rob, Simon, Armin , Maxime and all, > > Don’t get me wrong – I totally agree that ‘a distinction is > meaningless”. Given (a) the existence of an OGC standard (O&M) > and (b) the long time practice in SSN (whcih was only because of > (a)) , “Property” really does seem the sensible default. And its > easier to say! > > However, if indeed ‘Property" was too ambiguous” , and recognising > the painful double-meaning in RDF, and subject to something > sensible happening around here for Actuators, and noting that > ‘Observable property’ seems to be entirely equivalent in meaning > to “Property” in anyone’s use of it that I can see, > > and following up on Armin’s suggestion, > > We could > > (1) use Observable property in sosa > > (2) use “observable property” in ssn in the restriction context > (as in sosa) of a property that is the observedproperty of an > observation > > (3) in ssn assert observableproperty subclassOf Property > > (4) continue to use Property for all those other things that ssn > uses it for now, such as the superclass of “survivalrange”. > > (5) leave it to a user if they want to assert that those other > properties (e.g. survival range) are also subclasses of > “observableproperty” incase they want to observe it > > (6) fix rdfs:comments accordingly > > This is entirely consistent with my integration proposal but its > is MUCH harder than just sticking to “Property”. > https://www.w3.org/2015/spatial/wiki/Proposals_for_rewriting_SSN#Compromise_Proposal_6_made_by_Kerry_January_2017 > . And it a alows sosa-ssn interoperability perfectly (ie all your > observational instances still interoperate both directions). And > I can’t see the dul alignment being affected. > > Except it is NOT backwardly compatible for ssn users, who use > “property” for things that are observed. Ideas? Such users could > add “observableproperty equivalentclass Property” I suppose? We > could put this in ssnx ontology? Is it just much too late at > night for me to see if there is no problem here anyway – mihgt > have to have another look at observation to be sure. Maybe its ok > without the equivalent assertion… > > ØBtw: “But it is clear that some properties definitely are not > “observable” in any normal sense (e.g. “name”, “owner”, “creator”) > and could never be associated with sensing procedures or > instruments. “ > > I think that is in direct contradiciotn with our own definitions > of “observable property’, but I don’t care….see “Assertion’ type > below. Surely a human sensor can observe the price of an item in a > shop? Or the name of a person from a nametag? Or the creator of a > piece of art by studying its style? So can an image processing > sensor. Or maybe a barcode scanner. But it is not important. > > Change of topic… > > ØOn subclassing: why is it that you dislike having these in > alignments? Is there a principled reason for this application, or > does subclassing introduce some general difficulty that I’m not > familiar with? > > Lots of reasons. *But the most important one is the bi-directional > interoperability*. So you can take a ssn full instance , let a > reasoner run for all the instances, throw away any non-sosa terms > and voila you have a proper sosa instance. E.g. if you have a > sosa:observation subclass of ssn:observation you cannot do this. > OTOH you can take a sosa instance, and it is a fully formed ssn > instance just start decorating it as it is with any extra ssn > properties you want. E.g. if you have a ssn:observation subclass > of sosa:observation you cannot do this. > > Ok equivalentclass can do that right —but that ‘s inelegant for > other reasons. > > And its not an “alignment” --- what an ugly design to make an > ontology ”align” with its simple core! Truly bizarre. > > And what do we think we are doing to our poor users forcing them > to use the same term with two different prefixes in the same > ontology? Whoever would force that on anyone???? How are they > supposed to know what they are to do – even if they actually > notice there is a difference before they break everything. > > I should take on the task of formalising this property - I am > quite sure I did not invent it --- it is really important to me > or else how can sosa make any sense as a core of ssn?– and Jano’s > original modularisation proposal seems to have this property > anyway. Where did it all go wrong? > > *So … will you help?*Is there anyone out there that can understand > what I am saying yet? Maxime seems to get it!! I absolutely > cannot do this alone. > > Kerry > > *From:*Rob Atkinson [mailto:rob@metalinkage.com.au > <mailto:rob@metalinkage.com.au>] > *Sent:* Tuesday, 7 February 2017 6:07 PM > *To:* Armin Haller <armin.haller@anu.edu.au > <mailto:armin.haller@anu.edu.au>>; Simon.Cox@csiro.au; Kerry > Taylor <kerry.taylor@anu.edu.au <mailto:kerry.taylor@anu.edu.au>>; > janowicz@ucsb.edu <mailto:janowicz@ucsb.edu>; > maxime.lefrancois@emse.fr <mailto:maxime.lefrancois@emse.fr>; > public-sdw-wg@w3.org <mailto:public-sdw-wg@w3.org> > *Subject:* Re: Proposals (was Re: Architecture of SOSA/SSN > integration) : issue-87 only > > FWIW, my experience of people using O&M is that "Property" was too > ambiguous and people used it in rather arbitrary fashion - > strictly is should relate to a property of the feature being > observed, but with intermediate sampling features, and in general > the model of the observed feature not being available formally > this was generally too hard to unravel - and people tend to use it > as a surrogate for the procedure, or a generalised classification > of the subject, or just their cat's name or something. > > So I would suggest the current long-hand name of > "ObservableProperty" is helpful - and its an opportunity to > educate that "observations" may be performed by physical sensors > or via models. IMHO there are actually a chain of scientific > models in play for every physical sensor, and its all the same > thing and a distinction is meaningless. Sensors are a way to give > a shorthand identifier to part of such a chain, because the sensor > construction makes that chain immutable. > > Rob > > On Tue, 7 Feb 2017 at 13:44 Armin Haller <armin.haller@anu.edu.au > <mailto:armin.haller@anu.edu.au>> wrote: > > Kerry, you seem to be ok with recasting uses of Property in > SSN, as below. I note here that it does not have to be a > recasting of **all**, only where appropriate. There are > already several other subclasses of Property in SSN, e.g. > SurvivableProperty, OperatingProperty etc. which seem to be > introduced in SSN to make it easier for the user of the > ontology to know what is meant with “Property” in a specific > use of the class. The same would apply to ObservableProperty > that is introduced in the core, making it easier for the user > to know what this class means, in the absence of OWL axioms > that give the informed user a clue on its intended use. > > *From: *"Simon.Cox@csiro.au <mailto:Simon.Cox@csiro.au>" > <Simon.Cox@csiro.au <mailto:Simon.Cox@csiro.au>> > *Date: *Tuesday, 7 February 2017 at 1:29 pm > *To: *Kerry Taylor <kerry.taylor@anu.edu.au > <mailto:kerry.taylor@anu.edu.au>>, Armin Haller > <armin.haller@anu.edu.au <mailto:armin.haller@anu.edu.au>>, > "janowicz@ucsb.edu <mailto:janowicz@ucsb.edu>" > <janowicz@ucsb.edu <mailto:janowicz@ucsb.edu>>, > "maxime.lefrancois@emse.fr <mailto:maxime.lefrancois@emse.fr>" > <maxime.lefrancois@emse.fr > <mailto:maxime.lefrancois@emse.fr>>, "public-sdw-wg@w3.org > <mailto:public-sdw-wg@w3.org>" <public-sdw-wg@w3.org > <mailto:public-sdw-wg@w3.org>> > > > *Subject: *RE: Proposals (was Re: Architecture of SOSA/SSN > integration) : issue-87 only > > Thanks for exploring this Kerry. > > I agree that at least some ‘derivation’ processes fall into > our broad definition of ‘sensing’ and ‘observation’. > > Note that I did hedge the subclassing with the statement > > “These are not necessarily disjoint …”. > > But it is clear that some properties definitely are not > “observable” in any normal sense (e.g. “name”, “owner”, > “creator”) and could never be associated with sensing > procedures or instruments. > > So there is a spectrum, but I would suggest that in the SSN > layer at least we really are only interested in Observable > Properties, and it is likely that inventories of these could > be usefully assembled, alongside catalogues of sensors. And > that it is useful to keep these clear of the non-observable > properties. > > On subclassing: why is it that you dislike having these in > alignments? Is there a principled reason for this application, > or does subclassing introduce some general difficulty that I’m > not familiar with? > > Simon > > *From:*Kerry Taylor [mailto:kerry.taylor@anu.edu.au > <mailto:kerry.taylor@anu.edu.au>] > *Sent:* Tuesday, 7 February, 2017 12:37 > *To:* Armin Haller <armin.haller@anu.edu.au > <mailto:armin.haller@anu.edu.au>>; janowicz@ucsb.edu > <mailto:janowicz@ucsb.edu>; Maxime Lefrançois > <maxime.lefrancois@emse.fr > <mailto:maxime.lefrancois@emse.fr>>; Cox, Simon (L&W, Clayton) > <Simon.Cox@csiro.au <mailto:Simon.Cox@csiro.au>>; > public-sdw-wg@w3.org <mailto:public-sdw-wg@w3.org> > *Subject:* RE: Proposals (was Re: Architecture of SOSA/SSN > integration) : issue-87 only > > This subclass means that ssn instance data does not become > sosa-compliant instance data (I would love to have that if you > take all the instances of all the core terms out of an ssn > full instance you also have a usable sosa instance. I know > this is asking a lot… but I want bi-directional > interoperability which is implied by my proposal for > integration. I should have spelled this out earlier – and I > suppose it needs some formalisation to be useful. > > In this case if we really need “ObservableProperty)” ( and my > own view is that this is just silly vocabulary, and I’d much > rather keep “property” for O&M compliance anyway, nevertheless > I can live with it) I would like to check again whether > **all** SSN uses of Property could be recast as “Observable > property”. They are certainly not all “Observed” properties, > but given an explanation of what distinguishes “observable” > from others kind of properties I would look at the implications. > > OTOH looking at Simon’s ISO list : > > >-Observation > > >-Assertion (e.g. name, price) > > >-Derivation (e.g. classifications based on combinations of > observed properties) > > >-Inheritance/instantiation (e.g. where a property value is > assumed on the basis of class membership) > > >These are not necessarily disjoint, and it is likely that observable > properties are the most interesting (depending on you > epistemological viewpoint) >but it is useful to recognize that > observable properties are a distinct class. > > It is very clear that in sosa we do **not** want “observable > properties” because we have sensors that are computational > simulations making observations by ‘Derivation” so this may > not be Observable at all. And surely ours can also can be > “Assertion” (in the case the sensor is a human, for example). > Maybe even inheritance/instantiation too. For the latter if > we want to observe that some animal instance (such as > animals caught in my trap) has the property of being a member > of some species (e.g. “Homo Sapiens” ) on the basis of class > membership --Why not? Why should we prohibit that property > being observed? > > So this is a really strong reason why we should stick to > “Property” surely! If “Observable property” in this ISO vocab > means anything at all then it must be distinc t from the > union “Property” and so “Property” is what we need! > > I really dislike subclass alignments….and I dislike > equivalentclass almost as much, wherever they actually sit. > I way prefer using the same terms throughout, > > Which I tried to show in my proposal. > > Just catching up here so maybe I missed something. > > Thoughts? > > -Kerry > > *From:*Armin Haller > *Sent:* Tuesday, 7 February 2017 11:49 AM > *To:* janowicz@ucsb.edu <mailto:janowicz@ucsb.edu>; Maxime > Lefrançois <maxime.lefrancois@emse.fr > <mailto:maxime.lefrancois@emse.fr>>; Simon.Cox@csiro.au > <mailto:Simon.Cox@csiro.au>; Kerry Taylor > <kerry.taylor@anu.edu.au <mailto:kerry.taylor@anu.edu.au>>; > public-sdw-wg@w3.org <mailto:public-sdw-wg@w3.org> > *Subject:* Re: Proposals (was Re: Architecture of SOSA/SSN > integration) : issue-87 only > > The sub-class relation would only be introduced in SSN not > SOSA. I should have been more explicit in the second > dot-point. The third dot-point means to say that. > > *From: *Krzysztof Janowicz <janowicz@ucsb.edu > <mailto:janowicz@ucsb.edu>> > *Reply-To: *"janowicz@ucsb.edu <mailto:janowicz@ucsb.edu>" > <janowicz@ucsb.edu <mailto:janowicz@ucsb.edu>> > *Date: *Tuesday, 7 February 2017 at 11:44 am > *To: *Armin Haller <armin.haller@anu.edu.au > <mailto:armin.haller@anu.edu.au>>, Maxime Lefrançois > <maxime.lefrancois@emse.fr > <mailto:maxime.lefrancois@emse.fr>>, "Simon.Cox@csiro.au > <mailto:Simon.Cox@csiro.au>" <Simon.Cox@csiro.au > <mailto:Simon.Cox@csiro.au>>, Kerry Taylor > <kerry.taylor@anu.edu.au <mailto:kerry.taylor@anu.edu.au>>, > "public-sdw-wg@w3.org <mailto:public-sdw-wg@w3.org>" > <public-sdw-wg@w3.org <mailto:public-sdw-wg@w3.org>> > *Subject: *Re: Proposals (was Re: Architecture of SOSA/SSN > integration) : issue-87 only > > Not sure, whether I am fully understanding this. > > -ObservableProperty is a subclass of ssn:Property > > > This would violate one of our design principles, namely that > SOSA does not make use of SSN. > > > On 02/06/2017 04:41 PM, Armin Haller wrote: > > It looks like we have a proposal here to resolve issue 87: > https://www.w3.org/2015/spatial/track/issues/87 > > Please let me try to restate what was proposed: > > -ObservableProperty is introduced in SOSA (as is currently > implemented in: > https://github.com/w3c/sdw/blob/gh-pages/ssn/rdf/sosa.ttl) > > -ObservableProperty is a subclass of ssn:Property > > -ObservableProperty is introduced in SSN as well and the > subclass relation to ssn:Property is stated within > > That leaves the door open to have another property in SSN > (and) SOSA concerned with ActuableProperties. > > This should also mean that SSN instances are SOSA > instances, since no axioms in SOSA are violated. > > Is my understanding correct? > > *From: *Maxime Lefrançois <maxime.lefrancois@emse.fr> > <mailto:maxime.lefrancois@emse.fr> > *Date: *Tuesday, 7 February 2017 at 10:14 am > *To: *"Simon.Cox@csiro.au" <mailto:Simon.Cox@csiro.au> > <Simon.Cox@csiro.au> <mailto:Simon.Cox@csiro.au>, > "janowicz@ucsb.edu" <mailto:janowicz@ucsb.edu> > <janowicz@ucsb.edu> <mailto:janowicz@ucsb.edu>, Kerry > Taylor <kerry.taylor@anu.edu.au> > <mailto:kerry.taylor@anu.edu.au>, "public-sdw-wg@w3.org" > <mailto:public-sdw-wg@w3.org> <public-sdw-wg@w3.org> > <mailto:public-sdw-wg@w3.org> > *Subject: *Re: Proposals (was Re: Architecture of SOSA/SSN > integration) : issue-87 only > *Resent-From: *<public-sdw-wg@w3.org> > <mailto:public-sdw-wg@w3.org> > *Resent-Date: *Tuesday, 7 February 2017 at 10:15 am > > Yes indeed, this is what I meant. Thanks. > > Le lun. 6 févr. 2017 à 23:50, <Simon.Cox@csiro.au> > <mailto:Simon.Cox@csiro.au> a écrit : > > Øit appears very strange to me to state that a > ssn:property is a sub property of a > sosa:ObservableProperty > > ØThis is what can be read at [1] > > Assuming you mean “it appears very strange to me to > state that a ssn:Property is a sub class of a > sosa:ObservableProperty” then I agree. That looks like > my error. > > Simon > > *From:*Maxime Lefrançois > [mailto:maxime.lefrancois@emse.fr > <mailto:maxime.lefrancois@emse.fr>] > *Sent:* Monday, 6 February, 2017 17:55 > *To:* janowicz@ucsb.edu <mailto:janowicz@ucsb.edu>; > Cox, Simon (L&W, Clayton) <Simon.Cox@csiro.au> > <mailto:Simon.Cox@csiro.au>; kerry.taylor@anu.edu.au > <mailto:kerry.taylor@anu.edu.au>; public-sdw-wg@w3.org > <mailto:public-sdw-wg@w3.org> > > > *Subject:* Re: Proposals (was Re: Architecture of > SOSA/SSN integration) : issue-87 only > > ØAnd it appears very strange to me to state > that an observable property is a sub property > of a property. > > That was a slip of the tongue, I meant: > > it appears very strange to me to state that a > ssn:property is a sub property of a > sosa:ObservableProperty > > This is what can be read at [1] and is also what I > would model when Phil says: > > >>> Looking at the two definitions, there are differences > but they look > > >>> very minor to my eyes with sosa:ObservableProperty > looking slightly > > >>> more general, so, again, I'd delete ssn:Property. > > [1] - > https://github.com/w3c/sdw/blob/gh-pages/ssn/rdf/ssn-sosa.ttl > > > but anyways, +1 in favour of your arguments, and I > propose that: > > - we update sosa-ssn.ttl to reflect what we all agree on; > > - we also consider either to add > sosa:ActuableProperty, or roll back to just sosa:Property. > > Kind regards, > > Maxime > > Not strange actually – not all properties are > observable. In the revision of ISO 19109:2015 > we distinguished between > > -Observation > > -Assertion (e.g. name, price) > > -Derivation (e.g. classifications based on > combinations of observed properties) > > -Inheritance/instantiation (e.g. where a > property value is assumed on the basis of > class membership) > > These are not necessarily disjoint, and it is > likely that observable properties are the most > interesting (depending on you epistemological > viewpoint) but it is useful to recognize that > observable properties are a distinct class. > > Yes, not strange at all. I agree with all of > Simon's arguments and we also made them in one of > our telco's half a year ago. > > > > > On 02/05/2017 04:57 PM, Simon.Cox@csiro.au > <mailto:Simon.Cox@csiro.au> wrote: > > ØAnd it appears very strange to me to state > that an observable property is a sub property > of a property. > > Not strange actually – not all properties are > observable. In the revision of ISO 19109:2015 > we distinguished between > > -Observation > > -Assertion (e.g. name, price) > > -Derivation (e.g. classifications based on > combinations of observed properties) > > -Inheritance/instantiation (e.g. where a > property value is assumed on the basis of > class membership) > > These are not necessarily disjoint, and it is > likely that observable properties are the most > interesting (depending on you epistemological > viewpoint) but it is useful to recognize that > observable properties are a distinct class. > > Simon > > *From:*Maxime Lefrançois > [mailto:maxime.lefrancois@emse.fr] > *Sent:* Monday, 6 February, 2017 00:22 > *To:* Kerry Taylor <kerry.taylor@anu.edu.au> > <mailto:kerry.taylor@anu.edu.au>; SDW WG > Public List <public-sdw-wg@w3.org> > <mailto:public-sdw-wg@w3.org> > *Subject:* Re: Proposals (was Re: Architecture > of SOSA/SSN integration) : issue-87 only > > +1 for Kerry's arguments. > > And it appears very strange to me to state > that an observable property is a sub property > of a property. > > I just changed to sosa:Property instead of > sosa:ObservableProperty in the proposal I am > currently working on. > > + add relations and classes that are missing > > best, > > Maximle > > Le dim. 5 févr. 2017 à 13:44, Kerry Taylor > <kerry.taylor@anu.edu.au > <mailto:kerry.taylor@anu.edu.au>> a écrit : > > PhilA has said > > >>> Looking at the two definitions, there are > differences but they look > > >>> very minor to my eyes with > sosa:ObservableProperty looking slightly > > >>> more general, so, again, I'd delete > ssn:Property. > > This is issue-87. As you can see by my > analysis last November in the tracker > https://www.w3.org/2015/spatial/track/issues/87 > , > > (1). A sosa: Observable Property is NOT an > O&M property. The O&M standard has no such > term. > > (2) The ssn:Property has the same > intended meaning as an an O&M Property > (and, yes it is an O&M “Property”) and > this is explicit by the annotation within ssn “<dc:source> skos:exactMatch 'property' [O&M]http://www.opengeospatial.org/standards/om </dc:source>” > > > > (3) What is shown in the mapping table is > not the complete annotation for > ssn:Property – just an extract. However > that very paragraph deserves improvement. > > (4) ssn:Property is used in other places > throughout ssn that have nothing to do > with the narrow context associated with > Observation as it is used in SOSA. > > In particular, nothing to do with a > > (5) ssn:Property cannot be deleted --- > many, many things will break. Nor can it > be replaced by sosa:ObservableProperty > (see 4). Maybe it is possible to say > sosa:Property rdfs:SubclassOf > ssn:Property but this has its problems > too (ssn instances would not be sosa > instances). A more sophisticated > workaround is required if we head that > direction. > > (6) ssn users know it as “Property” . So > do O&M users. Why change, who are we serving? > > (6) OTOH a simple name change in sosa to > “Property” and some clarification on the > rdfs:comments in both places would work – > and then ssn and sosa can use the very > same term. This is the essence of my > proposal on the wiki as a pattern to solve > all these many problems. > https://www.w3.org/2015/spatial/wiki/Proposals_for_rewriting_SSN#Compromise_Proposal_6_made_by_Kerry_January_2017 > > In this case the rdfs:comment suggested by > Armin looks very close but I prefer > abbreviated as follows (due to (4) ) “An > observable quality of a real world > phenomena (thing, person, event, etc.) “ > or here is another idea that I propose > “An observable quality of a real world > phenomena (object, person, or event), > typically a FeatureOfInterest” . That > works well in the context for my proposal > that also shows how to use it in the > simple core. > > -Kerry > > Dr Kerry Taylor > > Associate Professor (Data Science) > > Research School of Computer Science > > ANU College of Engineering and Computer > Science > > Canberra ACT 2601 Australia > > +61 2 6125 8560 <tel:+61%202%206125%208560> > > -- > > 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 > > > > -- > > 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 > -- 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, 7 February 2017 22:18:05 UTC