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

Nicola wrote:
> 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)?

Actually, I never thought of visualizing (D,RD). The space (D,RD) contains the details that can be used (a "details library") with all connections within a detail ("intra-detail" connections) and, in addition, the potential connections between different details ("inter-details" connections).

Let me try:

interior ---------------------------------------+
  |  |                                           |
  |  |                                           v
  |  +----->   surface1|  <--- idoormat -->   surface2|
  |            :<-------------idoor ----------------->:

               :<-------------xdoor ----------------->:

The idea was that you can only choose a detail from the library to replace some "x" in your database if all connections to and from x in the space where 2x" lives are represented in the details library. For example, if you want to carry out road planning and have a crossing   x between two highways you cannot choose a traffic light crossing for x because in the details library there are no highways that are connected to a traffic light crossing - you can only choose among interchanges.

>>> 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.

Yes, I misunderstood. Within a topological database you can carry out all of these queries for subsets of the point set. I thought you wanted overlap in the geometrical representations of different spaces.

> 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,

I have made an SQL-experiment with Egenhofer's 9-intersections concept (which also falsifies some statements) which does that.

A set A is open in (X[id], R[p,dp]), when it satisfies:

     All t in R with t.dp in A satisfy: t.p in A .

The isOpen(A) pedicate (not tested):

     NOT EXISTS(
      SELECT t.p
      FROM   R t, A
      WHERE  t.dp = A.id
        AND  t.p NOT IN(SELECT id FROM A))

alternatively (also not tested):

     NOT EXISTS(
      SELECT t.p
      FROM   R t JOIN A ON (t.dp = A.id)
      WHERE  t.p NOT IN(SELECT id FROM A))

I have made CLOSURE, INTERIOR and BOUDARY queries in SQL (in the above mentioned experiment). These are code snippets. They have been tested with
  PostgreSQL 8.4.17 on a Debian Squeeze box with Linux 2.6.32-5-686:

---------------%<---------------%<--------------- create table X(id integer not null primary key); create table R(

   ida integer not null,
   idb integer not null,
   primary key(ida,idb),

--------------->%--------------->%--------------- [... some code omitted ...]
---------------%<---------------%<---------------

• Subset A:

create table A
( id integer not null primary key,

   foreign key(id) references X);

create view intA(id) as -- interior of A

   select A.id from A
   where not exists
    (select poR.ida from poR

     where poR.idb = A.id
       and poR.ida not in (select id from A));

create view clA as -- closure of A

    select distinct X.id from X, poR, A     where X.id=poR.idb and poR.ida=A.id;

create view bdA as -- boundary of A

    select clA.id from clA
    where clA.id not in (select id from intA);

create view extA as -- exterior of A

    select X.id from X
    where X.id not in (select id from clA);

--------------->%--------------->%---------------

Note: The foreign key from A to X forces

       A to be a subset of X.

 > 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?

The idea is to extend the query language, say SQL:

   create table X(id, .., say, color, ...);    create table R(a,b, FK(a) REF(X.id), FK(b) REF(X.id));    create space spX(X POINTS, R TOPOLOGY(a,b));

The you have ordinary tables, Spaces and can do:

   SELECT color FROM X WHERE Stuff;

to get an ordinary result table or you do

   SELECT color FROM spX WHERE Stuff;

to get a result /space/.

With object oriented programming (I used CLOS) you can dispatch the application of a query operator to either the spatial or the ordinary table method. Note that CLOS dispatches according to /all/ arguments not only to the first ("implicit" in Java or C++) argument.

When you mix spaces with ordinary tables the tables can be converted into discrete spaces by trivial wrappers:

This is copied from my prototype (and tested):

---------------%<---------------%<--------------- ;;; This makes DIFFERENCE applicable both for spaces and for relations: (defmethod difference-qop ((space-1 relational-space) (space-2 relational-space))

   ;; delegate to (space relation):
   (difference-qop space-1 (space-points space-2)))

(defmethod difference-qop ((rel relation) (sp relational-space))

   ;; delegate to (relation relation):
   (difference-qop rel (space-points sp)))

(defmethod difference-qop ((sp relational-space) (rel relation))

   ;; First delegate to (relation relation) and then compute the subspace:    (subspace-qop sp (difference-qop (space-points sp) rel))) --------------->%--------------->%---------------

difference-qop(relation relation) then actually carries out work and is defined somewhere else.

.

> Nicola

Norbert Received on Fri Dec 11 2015 - 09:19:28 CET