 However, since entities can have multiple types in a SemWeb based kb,
it is more challenging to effectively use the spatial index for this
query.


Existing spatial DBs can handle queries such as "get the five items
which match some column constraint and are nearest point Y."  Using
multiple types (as we might see in a SemWeb context) becomes to a
disjunction in the constraint.

Is the problem that the constraint matching attribute in the traditional
context is asserted but in the SemWeb context it may be inferred?

If so - my working view is that if one is using a DL (such as DL-Lite)
in which such inferences can be cleanly mapped into the RDBMS query,
this problem is already solved, hence the reduction to integration
engineering.  If your goal is to enable this with KBs of arbitrary,
unconstrained expressivity, I'm less confident - but then, I try to
avoid such KBs in practice :).

Avoiding KBs of unbound expressivity would indeed seem to be a problem. I certainly didn't intend to suggest that. However, I think that either you or I are somewhat mistaken about how NN indexing generally works. My impression (and I am far from an expert in spatial indexing) is that the k-aspect is generally handled within the index, meaning that splitting the query across multiple indexed-types would eliminate the gain.

Really, though, I was only attempting to offer this as one example in what will be a long list of small problems that are encountered as the community attempts to use Spatial Semantic Web Systems in places that Spatial RDBMS's have been used before. I think that we are going to see viable systems that cover the basics soon, but it will be a little longer before there is a system that can fully replace the current usage model of a spatial database.

--Dave--