This has probably been asked before, but I’ve been unable to find a good answer yet: what are the pro’s/con’s for adding an identifier in addition to :crux.db/id that also indicates the type? So for example adding a :person/id to all person entities?

Another strategy might be to add a :doc/type attribute to all entities

We use a type attribute for entities in our Site project. The pros are that it makes queries easier and less likely to return surprising results. It's also useful to allow entities to have multiple types, and Crux supports this well. We used a similar approach in Datomic with a type attribute of cardinality many. The cons may be that you need to support the evolution of such type attributes as you discover your domain. For that reason I feel it's better to encode a type in an extra attribute for this purpose than encode in the id itself. Entity ids should remain constant.

Another pro is that you can build type hierarchies. Crux supports recursive rules allowing you to build transitive properties (such as rdf:subClassOf). This is very useful. You can create powerful but small queries using this.

But be mindful of performance and ensure what you do is suitable for your data set (volume and complexity).

@malcolmsparks thanks for your answer. For now it’s just a toy project, so volume and complexity will be small.

@jlmr Prior to the HyperLogLog enhancement in 1.17 :type keys would suffer from their low selectivity (they don't usually have more than a handful of values to select from). Since HLL makes those queries fast, I'm pro :something/type columns, for sure.

📰 We have adapted the http://learndatalogtoday.org materials for Crux, see https://opencrux.com/tutorials/tutorials.html - all feedback is welcome! Also, we are keen to add more chapters soon, which topics would everyone here like to see?