This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # announcements (21)
- # architecture (6)
- # aws (18)
- # babashka (14)
- # beginners (231)
- # boot (1)
- # calva (2)
- # chlorine-clover (22)
- # cider (34)
- # clara (16)
- # clj-kondo (53)
- # cljdoc (5)
- # cljs-dev (22)
- # cljsrn (3)
- # clojure (283)
- # clojure-europe (24)
- # clojure-italy (9)
- # clojure-nl (5)
- # clojure-spec (5)
- # clojure-uk (57)
- # clojurescript (14)
- # core-typed (8)
- # cursive (4)
- # data-science (7)
- # datomic (41)
- # docker (24)
- # duct (2)
- # emacs (2)
- # exercism (29)
- # fulcro (96)
- # graalvm (4)
- # jobs-discuss (1)
- # kaocha (53)
- # lambdaisland (20)
- # malli (5)
- # nrepl (4)
- # observability (7)
- # off-topic (40)
- # pathom (44)
- # pedestal (8)
- # re-frame (19)
- # shadow-cljs (58)
- # spacemacs (2)
- # sql (9)
- # tools-deps (15)
- # vim (3)
- # yada (10)
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?
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.
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
with the usual caveat against premature abstraction: there may be a difference of meaning you haven’t discovered yet
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: https://docs.datomic.com/on-prem/schema.html#entity-specs
i.e., what are the things I could use an entity for and what constraints do I expect to hold
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
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. With SQL, you have to design your entity (subject). With Datomic, you can focus on your relations (predicates) instead. https://en.wikipedia.org/wiki/Resource_Description_Framework
> 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. He implies RDF, 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". : https://www.w3.org/DesignIssues/LinkedData.html : https://www.w3.org/TR/rdf-sparql-query/#basicpatterns
@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.
There's this https://github.com/cognitect-labs/onto. Also @U066U8JQJ has done some investigation into this area. https://www.amazon.com/Semantic-Web-Working-Ontologist-Effective/dp/0123859654 is a great book
Oh thanks @U5RCSJ6BB. I've seen https://github.com/arachne-framework/aristotle and https://github.com/quoll/kiara 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.
that book had a great effect on my modeling, I’m super glad @U5RCSJ6BB pointed me this book, great read!
@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 https://github.com/wilkerlucio/jena-clj/blob/master/src/main/com/wsscode/jena_clj/core.clj (disclaimer: I don’t consider it near production ready, just a bunch of random experiments)