Are Graph databases also categories?

[Zans Mihejevs]

Hi All, I've just come here from watching a talk by David Spivak on youtube that got me interested in FQL. 

The talk I've seen made the impression that FQL can be used as an alternative way to model relational databases, and the insights have been useful. 

Has anyone used the same method to model graph databases? I would be interested in hearing about your experiences or insight! 

[David Spivak]

Hi Zans,

Thanks for writing; I'm glad you're finding it interesting. I don't know of any formal writing on the subject of graph databases, but from a fairly cursory understanding, my belief is that they have a category-theoretic model that fits well with FQL. 

It's easier to go the other way, however, from FQL databases to graph databases. 

Given an FQL database instance J on a schema C, its "Grothendieck construction", Gr(J), looks like a graph database. You can check it out in one of the built-in examples to FQL. Gr(J) will be a new category that comes with a functor Gr(J)-->C. The nodes and arrows of Gr(J) form a graph, and the functor provides a C-label for every node and arrow in the graph. 

There is more one can say, but maybe I'll stop there. Does that help?

David

[Zans Mihejevs]

Hi David, thanks for the quick reply!

The Grothendieck constructions look really neat. I am glad that you confirmed my intuition on graph databases. Were there any specific properties that made relational databases more suited for your needs as compared to graph databases when you decided to create FQL? My naive intuition would have thought that since graphs are closely tied to categories already, it would have been a good match!     

Or are you saying that from the point of view of category theory both relational and graph db's are equivalent?

Also, you have mentioned Ologs in your talk, and they sound like a very interesting idea that I'd like to explore further. Particularly, I would be interested in seeing if there exist examples of ologs for collecting mathematical definitions. Have you ever seen or tried building one like that? 

--
You received this message because you are subscribed to a topic in the Google Groups "categoricaldata" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/categoricaldata/b0ifMPnC8Bw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to categoricalda...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[David Spivak]

Hi Zans,

Were there any specific properties that made relational databases more suited for your needs as compared to graph databases when you decided to create FQL?

Categorical databases are really not entirely aligned with relational databases. The reason we usually present things in a relational style is A. it's familiar to people, B., the relational world currently has more formal theory for us to latch into. But categorical databases are really their own thing.

Or are you saying that from the point of view of category theory both relational and graph db's are equivalent?

I don't think that graph databases will be equivalent to relational databases, but I wouldn't be surprised if there was some sort of adjunction between them. However, to state that with any sort of authority would require a deeper understanding, and perhaps some minor reworking, of what we mean by graph databases in this context.

Particularly, I would be interested in seeing if there exist examples of ologs for collecting mathematical definitions. Have you ever seen or tried building one like that? 

I have tried briefly, but the task was monumental, and didn't quite seem worthwhile. Ologs are in some sense just descriptions of sets, functions, equations, unions, etc. Since mathematics has been (at least ostensibly) founded on set theory, it should be the case that all mathematical structures could be described by ologs (or by some extension of them). However, no one really thinks about mathematical objects set-theoretically. So it's unclear whether this olog (which would be enormous and terribly unwieldy) would have any real use, even pedagogically. Still, if you'd like to try it out, I don't want to discourage you.

Best,

David

--
You received this message because you are subscribed to the Google Groups "categoricaldata" group.
To unsubscribe from this group and stop receiving emails from it, send an email to categoricalda...@googlegroups.com.

[Zans Mihejevs]

Hi David,

Thank you for the insights, the perspective has been useful. 

I would be interested in exploring the connection between FQL and graph databases further, but at first I would like to get a deeper feel for FQL. 

My main question  is, how would you represent time-series data in FQL? My understanding of your talk is that columns are equivalent to arrows, which was a brilliant insight. However in a time series the main interest is the change of values across the time dimension, with each temporal snapshot being represented by a distinct row.   

How could that be expressed using the language of category theory? Would it make sense to say that there is there an arrow T going from one row to the next?  

So far the examples I've seen have referred to static data, rather than change over time, so I am interested in seeing how this kind of problem could be approached. 

In terms of a mathematical olog, that's quite a shame that it's not been done before. I understand the monumentality of the task, but of course I did not mean to encode all of mathematics, just some areas of interest. 

I think I would be quite curious to try. 

[David Spivak]

Hi Zans,

Time series data is an interesting case. For example, in "insert-only" databases, you could multiply your schema C by the "time line" T, the poset of natural numbers 0~>1~>2~>.... You then enter your data into a table c in C at a given time t, i.e., in the object (c,t) in CxT. But for complex notions of time, or for temporal databases that are not insert-only, more theory may be required. 

Different applied category-theorists think of updates in different ways. Some think of them as natural transformations, or spans thereof (I used to think this way), but I think of them as endofunctors F:C-Inst~>C-Inst. That way, updates are "commands" that convert instances to instances. I consider an insert update to be a pointed endofunctor, i.e., a functor F, together with a natural transformation J~>F(J). Similarly for delete updates. 

Databases whose state change in time (i.e., all databases) may be understood as a log file of updates, i.e., functors, which can be composed to result in the current state of the databases. Schema evolution and queries fit nicely into this picture, because everything (change of schema, ETL, queries, updates) are all functors between instance categories.

Does that help?

David

[Zans Mihejevs]

That does help a lot, thank you, David!

Since we are now dealing with functors that act on the whole database, does that mean that in order to model the entire system we need to also include a category(meta-database?) of all possible states that the database can take and all the possible functors that can act on it? 

[David Spivak]

In order to think about instances and queries, yes, you can think about C-Inst, the category of all instances on C. Given a functor C-->D, you obtain ways of moving data back and forth, functors C-Inst --> D-inst and D-Inst-->C-Inst.

However, you certainly do not need to store all that. The category C-Inst is, of course, infinite. 

[Zans Mihejevs]

That's great, it really helped me think clearer about this, thank you for your help :)