Comments on Norbert's topological extension of relational algebra

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.
   
2. Norbert made an example using the following instances (copied from a previous post):

   S = sid detail

       int1   interior
       door   xdoor
       garden exterior

         <---interior--->|<----boudary--->
   RS =  isid  idetail   -  bdsid  bddetail
         ----------------------------------
         int1   interior -  door   xdoor
         garden exterior -  door   xdoor

   D = did          detail
      ----------------------------------------------------
      interior     interior
      exterior     exterior
      surface1|    idoor
      surface2|    idoor
      surface||    xdoor
      surfacex|    xdoor
      idoormat     idoor
      xdoormat     xdoor

        <-----interior---->|<-----boudary------>
  RD =  idid     idetail      bddid      bddetail
        ---------------------------------------
        interior  interior    surface1|  idoor
        idoormat  idoor       surface2|  idoor
        interior  interior    surfacex|  xdoor
        exterior  exterior    surface||  xdoor
        xdoormat  xdoor       surface||  xdoor

Then, he computed the topological natural join between (S,RS) and (D,RD) and said that the result is:

   RSD = isid    idetail   idid         bdsid  bddetail  bddid
         ---------------------------------------------------------
         int1,   interior, interior,    door,  xdoor,    surfacex|
         door,   xdoor,    xdoormat,    door,  xdoor,    surface||
         door,   xdoor,    xdoormat,    door,  xdoor,    surfacex|
         garden, exterior, exterior,    door,  xdoor,    surface||

If I am not mistaken, however, the result should be:

   RSD = isid    idetail   idid         bdsid  bddetail  bddid
         ---------------------------------------------------------
         int1,   interior, interior,    door,  xdoor,    surfacex|
         door,   xdoor,    xdoormat,    door,  xdoor,    surface||
         garden, exterior, exterior,    door,  xdoor,    surface||

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.

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

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

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?

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

Nicola

• news://freenews.netfront.net/ - complaints: news_at_netfront.net ---