Re: Comments on Norbert's topological extension of relational algebra

From: Nicola <nvitacolonna_at_gmail.com>
Date: Thu, 10 Dec 2015 23:18:24 +0100
Message-ID: <n4ctng$25g3$1_at_adenine.netfront.net>


On 2015-12-10 15:54:21 +0000, Norbert_Paul said:

>
> I also thought of the tuple
>
> RD(interior,interior, surfacex|,xdoor)
>
> which should express, that an xdoor has one surface
> towards the interior of the building.

That is already in RD.
>
> When you recalculate with the above tuple added to RD then you should
> get my result.

I don't, but I'll double-check tomorrow.

> Note that the xdoor will always be added with correct
> orientation: Interior surface towards cozy interior and (weathered)
> exterior surface towards rain and sunlight stress.

Are xdoor and idoor parts of the same door?

interior-----idoor xdoor-----exterior

             |---door---|

If so, how can xdoor have a surface in contact with the interior? Could you draw a diagram for (D,RD)?

>

>> may be
>> that the topological algebra is even too expressive for practical purposes:
>> for example, I can imagine that a useful operation might be "zooming", or a
>> change in granularity, where you have a topological space containing a
>> point x
>> and you replace x by embedding another topological space (modeling the
>> parts x is made of). I am not sure whether "glueing" is the correct term
>> for
>> it. I think that select (or difference) and union alone may achieve that.

>
> The (S,RS) and (D,RD) example should illustrate "change in granularity".
> (S,RS) is the coarser (less granular) view on (S,RS)JOIN(D,RD).
> Topological projection is "zooming out" (with a grain of salt).

Ok, intuitively that may make sense. I can't see that in the example, but again, that is because I am not able to visualize it yet.

> "Overlap" involves geometry. I started to work on that but it still is
> an open issue. Assuming you have an "INTERSECTS" predicate for tuples the
> OVERLAP query is a mere selection
>
> THETA(a) := INTERSECTS(a,this_region) .

Shouldn't you be able to recover all the topological relations between objects from a topological database? I think that the point of encoding the topology in a relation is exactly to avoid the need for additional predicates like INTERSECTS.

The problem I am considering is this: you are given a topological database (X,R) and an open (or closed) set A (a subset of X). What are the open sets that [overlap|contain|are inside|...] A? What is the closure/boundary of A? In principle, you should be able to answer those queries because R encodes the topology of the space, shouldn't you? It is not clear to me, however, how you would represent the output: it would be nice if it would always be a topological (sub)space (hence, as a topological database). Another question is how you can compute the output from R (or R*) directly, without building a topology explicitly. Is this a direction that you have explored?

Nicola

Received on Thu Dec 10 2015 - 23:18:24 CET

Original text of this message