Re: A Topological Relational Algebra in Lisp

On Saturday, January 17, 2015 at 3:07:12 PM UTC-8, Norbert_Paul wrote:
> Tegiri Nenashi wrote:
> > Can we lower discussion level a little? Instead of topologies lets focus on metric spaces. Now consider multivariate relation:
> >
> > x y z
> > -----
> > 1 1 1
> > 2 1 1
> > 3 2 1
> > 3 2 2
> >
> > What metric space do you expend this relation to?
>
> I will call that relation "X".

X capital is fine (as long as reader is not confusing it with lower x which is the first attribute).

> Then, of course, the metric space will be the discrete space (X.P(X)) where
> P(X) is the power set of X. It will be modelled as
> (X,\emptyset)
> because the empty set creates the discrete topology.

What is the power set of a relation? Most of the time, when people refer to set structure of relation they mean set of tuples. Therefore, I interpret your answer as

{{},{(1,1,1)},{(1,1,1),(2,1,1)},...,{(1,1,1),(2,1,1),(3,2,1),(3,2,2)}}

Why this is an interesting object? It seems that further along you argue it isn't?

> Actually, when considering databases, I am not (yet) interested very much in
> metric topologies for databases.

Metric space is something that you can explain to undergraduate student from STEM field. I doubt every math major undergraduate can coherently explain what abstract topology is.

This is one of the reasons why databases enjoyed such a success. The basic object is a predicate -- a concept easily grasped by anybody taking introductory course in mathematical logic.  

> The reason is that a database relation is always finite (one might dispute that
> but it is a assumption a make). My model so far only considers finite database
> relations, and takes them as topological point sets. But a finite metric space
> is always discrete (where every subset of the point set is open), and, hence,
> quite uninteresting.

Forget about metric spaces then. Can you elaborate a toy example with one or two relations and what topological objects they correspond to?  

> Whereas I consider the discrete topology a "default" topology for bare sets
> (database relations with no explicitly defined topoology) in my concept,
> it is a commonly known fact that finite metric topologies are always discrete.
> Discrete topologies are an important extreme (like the universal relation in
> relation theory) but not of much practical interest within my concept.
>
> On the other hand, topological spaces that serve as a physical model of
> topologically organized data (say, R^3 for spaes or R^4 for space-time
> models) have their natural (metric) topology. So I do not neglect metric
> topologies. IMHO they just do not have a relational representation for
> interesting practical applications.
>
> However, when spatial entities that live in some R^n (R^2 - the plane, R^3 -
> the Euclidean space, R^4 - the space-time, ...) are modelled and
> (according to my assumption) are partitioned into a a finite set of spatial
> entities (say, faces, edges, volumes, hyper-volumes, ...) then the set of
> entities immediately fits into my model (for being finite). Interestingly the
> entities get their topology by the same operations that produce topological
> result spaces from input spaces (so-called !quotient space"). Anyhow, the
> resulting topology for these entities (like an edge being bounded by vertices)
> usually does not constitute a metric sapce any more.

Again, in order not to loose your reader (me), can you please exhibit an example? For example, take a concrete simplicial complex, are you saying you have innovative way to represent it "relationally"? (Please keep the example concrete).

> Maybe, however, your post might be the start of developing a concept to
> introduce concepts for metric topologies. Note, however, that, in order to get
> interesting topologies (not only the dioscrete one), the point set must be
> infinite.

No, if metric space correspondence is vacuous, there is no point elaborating this -- I understand that metric space view can be not interesting, while topology offering some nontrivial insight. Received on Sun Jan 18 2015 - 00:58:57 CET