Indeed, unless that triple store specifically implements an implied rule that all the different ways of writing a given georeference are "same-as". We can write an OWL rule that specifically handles some particular coordinate (by crafting a regular expression that matches that coordinate),  but not one that handles any location.

Time and date has a similar problem. This is managed by date and time being treated as a primitive value with "facets". The specification describes the various lexical forms and how to deal with them, but that specification must be implemented in code.

It seems to me that this would be the way to go with georeferences and polygons. They should be an OWL data (with a datatype), not owl resources. Things that don't know about particular datatypes treat their various lexical representations as opaque. But looking into a bit further, OWL datatypes are limited in expressivity because the restriction value of a datataype restriction must be a literal. There is no easy way to say "a thing is near Sydney if the polygon that's 100km larger than its polygon intersects Sydney's polygon".

Oh well.

Perhaps the real problem is that we are trying to do to much with vocabulary. OWL and RDF are not really built for performing any sort of numerical calculation - there is no add or subtract in the OWL language at all.  But if you are serving up SPARQL, then the engine could do some magic. For instance, we could parameterise georeference queries as annotation properties like so:

* declare distanceFromSydney as a subproperty of geo:calculatedDistanceFrom

* add annotations to the distanceFromSydney property:

* geo:useLocationOf #Sydney

An engine that does geo can now treat everything with a location as also having a property "distanceFromSydney". You search on this with the existing tools for defining classes with numerical values within certain ranges.

_______________________________________________