Fork me on GitHub

I've always interpreted Rich's The Language of the System as speaking about Clojure. Clojure is meant to be part of some whole. Clojure is not meant to become its own island that can only send messages to other islands. Rather, Clojure can fit nicely as part of a river, and work effectively even if it relies on some upstream source of truth. Does The Language of the System also describe the use of Datomic?

Alex Miller (Clojure team)12:04:52

It’s intentionally not about either

Alex Miller (Clojure team)12:04:08

And also about both of course


That seems right to me. I think my brain would hurt less with examples / stories where Datomic was used to solve observed problems. I've seen most talks I've found about Datomic, though. Context: In my daily work with Java, I suspect that we're suffering from a "situatedness", where teams become islands with their own vaguely different entity definitions. I'm not precisely sure what the solution to that should be. But I suspect that understanding Datomic better could help me improve our state. So far, thinking about RDF and specs with global names has been helpful.

Alex Miller (Clojure team)13:04:51

those sound like good ideas to me


What has proved to be better practice, to try to keep all attributes of a entity use the same namespace or to mix various namespaces in an entity? the latter looks messy to me


the meaning of the attrs themselves should guide that imo


with the usual caveat against premature abstraction: there may be a difference of meaning you haven’t discovered yet


to clarify, you are saying namespaces should not scope an "entity type" correct?


that example uses single ns for entities


or maybe it shows co-occurence clusters of attributes on entities? troll


what I mean is, for example, if you have an attribute with the same meaning no matter what entity “type” it appears on, don’t split it into multiple attributes just so entities never have attributes from other namespaces


data-modeling-wise, focus on attributes and their meanings, build entity “types” later, if that’s even necessary


In sql ERDs, you might engage in “polymorphic joined-table inheritance” tricks to share columns across tables, or simply copy the same column name into multiple tables. This doesn’t make sense in datomic since you can assert any attr on anything.


fair, I guess I'm getting to hung up in making entities look "elegant" instead of applying common sense but I get your point: namespaces scope a set of attributes, not "entity types"


what you really want (in datomic) are entity specs rather than types:

👍 4

i.e., what are the things I could use an entity for and what constraints do I expect to hold


but an entity may fulfill many specs at once, or some only some of the time


so again, it’s contextual, not baked in to the entity itself as a type


specs give you: required attrs (:db.entity/attrs), and enforcing cross-fact constraints (:db.entity/preds)


there are also attribute predicates which constrain attribute values further than their type (:db.attr/types), but they are on the attribute not entities, so again they’re expected to be universal


this brings an annoying modeling limitation where you may want an attr with a universal meaning, but contextually want it to have a narrower possible range of values. this is common when dealing with data modeled by XML schema or OOP-ish type systems, where some “refinement” mechanism is used commonly


in datomic, you have to decide whether to leave some attr constraints a bit loose and untyped, or split each refinement into a different attr and lose some universality


> fair, I guess I'm getting to hung up in making entities look "elegant" instead of applying common sense but I get your point: namespaces scope a set of attributes, not "entity types" How about making your system for namespacing relations elegant instead?


@U09R86PA4 was reading the attr-preds and entity spec stuff and see what you mean, helpful thanks.


I know they have different purpose, but couldn't entity predicates be use as attribute predicates too? and you get to choose at transaction time when to apply them


@U3X7174KS don't know what you mean, can you elaborate?


When I first had a look at Datomic, I had the urge to get "nice tables". That eventually got me into the same troubles that I would have if I were to use plain SQL tables: I wan't able to make a "rectangular" structure that fit; what would I do about missing data? Datomic doesn't require "rectangular" data. Missing data is okay. When missing data starts becoming okay, you start to think in terms of relations (predicates) first. And those predicates tend to (in my experience) be simpler to describe accurately than the entities. Picture from the Wikipedia page on RDF, which also "thinks in terms of relations (predicates) first[1]. With SQL, you have to design your entity (subject). With Datomic, you can focus on your relations (predicates) instead.

👍 4

> but couldn’t entity predicates be use as attribute predicates too? Yes, you can check anything you want in an entity predicate


I find this topic to be abstract, hard to understand, and hard to explain. So I went looking for a knowledge graph it's possible to explore to illustrate. Didn't find a good one. What I did find was Tim Berners-Lee arguing for the use of linked data on the web[1]. He implies RDF[2], but Datomic can be used similarly. Sorry for throwing new stuff at you. In the article, FOAF is an example of a "system for namespacing relations". [1]: [2]:


@U3X7174KS about your wikipedia comment, in datomic, you still have to think about how to group those attributes as entities though


In my schema, I model using rectangular entities so they fit with integrations to relational dbs. attributes for each entity share a namespace (as you suggest) but there is also a single “all” namespace for attributes that are shared by all entities e.g. :all/id which is a uuid, :all/type for dispatch etc.


Is anyone aware of successful examples of integrating OWL ontology terms into a Datomic database? Or thought about how it could be done (or why it shouldn't be done)? There seems to be so much conceptual overlap between Datomic and 'semantic web' technologies (RDF, OWL, JSON-LD) but little technical interoperability.

❤️ 4

Oh thanks @U5RCSJ6BB. I've seen and and I'm sure I've stumbled on onto before but haven't looked at it recently. I was just looking at that 'Working Ontologist' book on amazon earlier today.


np! there's also a #rdf channel


that book had a great effect on my modeling, I’m super glad @U5RCSJ6BB pointed me this book, great read!

👍 4

@U066U8JQJ Have you been able to integrate terms from OWL ontologies somehow as attributes in datomic schemas? Or could you point me to any other resources for clojure/rdf interoperability?


@U1MBP9HV2 I did play with Jena, got to write some wrappers to work on Jena in similar fashion of datomic, but just as an experiment, I agree they share a good portion of principles (not by accident, datomic is based on RDF ideas), but I didn’t tried to integrate in the rest of the system, if you wanna look at that jena wrapper its here (disclaimer: I don’t consider it near production ready, just a bunch of random experiments)


Thanks! At this point I'm trying to just put together a small proof-of-concept so I don't need anything production-ready.