Re: Comments on Norbert's topological extension of relational algebra
Date: Thu, 10 Dec 2015 16:54:21 +0100
Message-ID: <n4c72p$cjq$1_at_dont-email.me>
Nicola wrote:
> I'd like to start a new thread about the topological extension of RA
> proposed
> by Norbert Paul in this group last January. First of all, let me say that I
> find the idea of representing a topology relationally through the
> specialization preorder quite attractive for its simplicity. And let me add
> that my knowledge of topology is very weak, so please be patient with me.
I appreciate being noticed, so, of course, I will be patient.
> Before I make a few comments, I think that there are a couple of things
> to be
> corrected, one in the paper and one in a previous post:
>
> 1. Example 6.7 from the paper contains a small mistake. The example says
> that,
> given a topological database (X={a,b,c,d}, R={(a,c),(a,d),(c,b),(d,b)}),
> the
> subspace topology on {a,b} does not contain {b}. But the topology
> generated by
> R is {∅, {a,b,c,d}, {b,c,d}, {b,c}, {b,d}, {b}}, so the subspace on
> {a,b} is
> {∅, {a,b}, {b}}, which contains {b}. The subspace is correctly generated
> by R+
> ∩ {a,b}^2 = {(a,b)}, but not by R ∩ {a,b}^2 = ∅, so the point of the
> example
> (the necessity of computing the transitive closure) is valid anyway.
We have adopted the convention that a topology-defining relation
a R b should be read as b is in the closure of {a}.
This convention is arbitrary.
With this convention {a} is open and, hence member of the topology
and {b} is not open (it is closed). If you transpose the incidence
relation (or use the other convention) {a} is closed and {b} is open.
Note that the example only /illustrates/ the necessity of computing the transitive closure and does not yet prove it.
> 2. Norbert made an example using the following instances (copied from a
> previous post):
[...]
> Regarding this example, could you provide a geometric intuition about
> how this
> space is organized (ASCII art would be ok)? I understand (S,RS), but
> (D,RD) is
> not clear to me (let alone the join - see below): it seems to me that there
> are too many surfaces and too few relationships.
(S,RS)
---int-------------+----------ext---
door
interior xdoor exterior
door is the common boundary of int and ext. It is of type xdoor.
You are right, there is an error. I hope, you are patient.
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. I forgot to put it into
When you recalculate with the above tuple added to RD then you should get my result. 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.
> That said, the main issue I have with the approach (which others have
> raised,
> too) is one of interpretability. Topological select (i.e., subspace) is
> intuitive, but Cartesian product (i.e., space product), hence join, is not.
> Group by (i.e., quotient space) even less. I mean, I understand the
> constructs, but I do not clearly see how useful they might be in practice
> (people in BIM do not work with Klein bottles that often, I guess). It
Not that often, indeed:
http://en.wikiarquitectura.com/index.php/Klein_Bottle_House
Cartesian product is generalized extrusion:
*-----------*
|\ |\
| \ | \
* | *-----------*
| | | | |
| *-----------* *--|--------* |
| x \ \ = \ | \ |
| \ \ \| \|
* *-----------* *-----------*
CAD Macro-Objects (BLOCKs in AutoCAD) can be considered special cases of join.
> 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.
Union and pasing are different notions but very closely related: Pasting is a quotient of a disjoint union. In special cases union alone is already a pasting. Disjoint union alone is a pasting: It has the attaching map f:{} -> Y.
Replacing x by embedding another object is exactly the application I have in mind for the natjoin.
> Second, in the example above, the join is made on a detail attribute
> (that is,
> not on a key). Would a join on key attributes between two topological
> databases be meaningful? Intuitively, you would keep the points that
> belong to
> both spaces and combine their topology through product... How would you
> interpret the result? Would it make sense to think about it as building a
> space with more dimensions (e.g., one space gives the topological relations
> among points on axis x, the other on axis y, and the join would build
> 2-dimensional objects)?
The axis example is Cartesian product, a special case of join: The X-axis has key attribute "x" and the Y-axis has key attribute "y". The join has Key {"x","y"}.
I don't know if equi-join on key attributes is meaningful. I initially wanted to carry out topological constructions with database queries. Only later did I find out, that the basic query operators themselves can be turned into topological constructions. It now may turn out that some do not have obvious applications (yet) but the operators are just there and maybe they are of use.
At the first glance, an equi-join on keys looks to me as if it essentiallly was an intersection. Note that intersection is a natjoin on superkeys.
> Third, something that is not mentioned in the paper is how you would
> perform
> computations with the topological algebra, e.g., answer topological queries
> such as: "give me all objects that overlap this region". Say, you have a
> topological database (X,R): how do you formulate the previous query (and
> how
> do you model the region of interest)?
> Fourth, the example above mentions real objects (doors, gardens, ...).
> But in
> the paper a significant amount of space is devoted to CW-complexes
> (which I am
> not sure I have understood yet). In a "real" application, would the X in a
> topological database (X,R) be made of CW-complexes (or simplexes, or
> something
> else)? Or, what would be the place of CW-complexes in the database?
We started our work with CW complexes. They have the handy property of giving orientation (front/rear side, starting/ending vertex, etc) to elements. This is an important property. However, we found out, for example, that an OVERLAP query sometimes gives strange (but formally consistent) orientations:
Note the last sentence in "4 Simplex Intersection"
I think of complexes as an optional feature for relational representations of spatial objects. It is an important feature but there are still open issues.
> Ok, these are the things off the top of my head that may be asked from the
> point of view of a practitioner (from a theoretical point of view, the
> paper
> looks sound to me and, as I said, the underlying idea is appealing).
Thanks. There is still much to do. However, I had to quit that buiness.
> Nicola
Norbert
Received on Thu Dec 10 2015 - 16:54:21 CET