1. 7

  2. 5

    Thus, the structuring of information characteristic and critical to the SQL-style modelling, where relevant pieces of data are grouped together in records, is faithfully preserved in hypergraphs. In general, the hypergraph data model can seamlessly accommodate any relational information.

    Conversely, the structure of any hypergraph can be faithfully described as a relational schema. Even better, relational schemas can distinguish between legitimate and illegitimate associations in a way that is not possible if you just say “everything is a vertex or an (hyper)edge”. If you do distinguish between kinds of vertices and edges, you have basically reinvented the relational model.

    Furthermore, the strictness of the SQL schema makes it very hard to cater for irregular or incomplete data instances, e.g., an odd instance of polygamous marriage showing up in the data set, or an instance with missing information about one of the spouses.

    This is a virtue. It forces you to think about the structure of your data, and how it can accomodate edge cases.

    That being said, the relational model does have expressiveness limitations. However, those are fixed with more powerful modeling tools, not by getting rid of modeling tools. For example, you can say a database is an I-indexed diagram on the category of sets, with I being the schema.

    • Each primitive domain entity is a finite set, e.g., customer, product, invoice.
    • Each attribute is a function, e.g., Product.price : product -> numeric, Invoice.customer : invoice -> customer.
    • Function composition is the main operation for building complex queries.
    • Monoids, esp. commutative ones (e.g., numeric with either addition or multiplication) allow you to summarize data in an automatically parallelizable way.
    • To optimize queries (at the expense of updates, of course), you can physically store the result of composing functions, but this has no bearing on the schema’s semantics.
    • Derived domain entities to be defined using universal properties, e.g., product = physical_product + service_product.

    relationships (connections) in data are first class-citizens

    No more and no less than when you use association relations.

    1. 3

      Well said. And yeah, I mean, I’d have more sympathy for the polyamorous relationship example in this context if hypergraphs similarly accommodated other common ways in which schemas can harm people, such as limited concepts of how gender work, or assumptions about names. They don’t; it’s a cherry-picked example.

      I agree with you that it’s better to explicitly consider these cases. Sometimes the correct action is to leave the field out entirely, sometimes it’s to rethink the structure a little.

    2. 2

      Good intro into a relatively obscure corner of CS! Looking forward to the sequels. Search, esp. isomorphic search in hypergraphs is where it starts to get tricky.

      1. 1

        What I like with GRAKN is that they allow the use of hypergraphs and inferences on top of it in a very easy and straight forward way. Do you know of any resources on isomorphich search in hypergraphs (Sorry I did not look for it)

        1. 2

          Nothing specifically for hypergraphs AFAIK, but then am no expert. There are several methods for ordinary graphs which one can use as a starting point, good summary is here. Wish I read it before I started my pet project that makes use of HGs. Ended up basically re-inventing neighbourhood signature pruning, a la GraphQL. However I don’t have enough theoretical training to claim it’s the best approach.

          1. 1

            Thank you.