The Importance of Namespaced Keywords
This post is motivated by this question from reddit:
ISAK_S: Isn't fairly rectangular still the common case even with datomic? I could see having meta namespaces across multiple 'types', but you wouldn't normally have
blog_post/namespaced attributes on the same entity, would you?
which I think is answered by Rich here:
RICH HICKEY: We want to be able to merge data from different sources, we don't want the schemas to dominate the semantics, right? How many people have ever gotten the same piece of mail from the same company and been like, "what is wrong with your databases, dudes?", right? Yeah. What is wrong? What's wrong is, one company bought another company, right? Now they're the same company, they now have these two databases. In one database, your name is in the person thing and in another database your name is in the person table and in another database your name is in the mailing list table, right? Who knows that mailing list table name and person name are actually the same piece of information? Nobody. They have to have meetings, I mean this is a big dollar, this is a big ticket problem. It's not a small...it's not a laughing matter, right?[audience laughter]Right? These big companies have giant jobs trying to merge these systems because, because table parochiality, it's the same as classes and algebraic data types. It's the same problem, it's not a different problem. It's all like, I had this view of the world and on the day I decided how the world is I decided that names were parts of person, and you decided that names were parts of mailing lists. And now we need to fix this. And you know how a lot of those companies fix it? They introduce a third database, usually an RDF database as a federation point so they now can figure out these two things are the same. And eventually they will stop sending you two pieces of mail...the same piece of mail twice.Right, so this is subject, predicate, object and obviously you can see the influence of this on Datomic.
Because Datomic entities are open like hashmaps, we can mix and match different namespaces without declaring up front the set of legal attributes. This means you get free functionality without writing any new code or models.
This design is very powerful and opens the door to many possibilities.
For example, Hyperfiddle can express ideas like "this is thing has :post/markdown so render it as markdown, and it also has :db/ident which means it is URL routable, and it's also got a :hyperfiddle/datomic-query so load that data."
Attributes define semantics
Because of the namespaced keywords, the system knows the exact semantics of each of these things. Given an attribute like
:github/markdownyou can figure out:
- Who is the maintainer
- Where the docs are describing what this attribute is for
- Where you might find Clojure code that process the values
Sometimes many attributes work together. A set of attributes becomes a vocabulary of concepts, aka a "semantic ontology":
Wikipedia ontology: Every field creates ontologies to limit complexity and organize information into data and knowledge. As new ontologies are made, their use hopefully improves problem solving within that domain.
- Friend-of-a-friend ontology
- HTML link relations
- Hyperfiddle ontology as it exists today
- www.dustingetz.com ontology for blogging (C-f "post/", this one is kind of a mess)
- Datomic contains an ontology for defining ontologies
- FOAF ontology uses namespaced attributes, just different syntax
- The link-relations ontology doesn't have namespaces thus it needs a centrally controlled registry
Semantics drive functionality
Ontologies are meant to be shared and reused from many contexts. Hyperfiddle leverages this idea to let you create by mix-n-match of ontologies.
For example, we could make a Github issue app with checkboxes by leveraging the following ontologies:
- :db/ident – for URL routing
- :hyperfiddle.post/markdown – for markdown rendering with extensions
- :hyperfiddle/datomic-query – for loading data
- :dustingetz.todo/completed, :dustingetz.todo/title
The :dustingetz.todo ontology comes with attribute renderers for :dustingetz.todo/completed and :dustingetz.todo/title, and may also include sets of useful queries and forms, like :dustingetz.todo/active-todos and :dustingetz.todo/new-todo. It probably also contains Clojure specs for your attributes and forms. Similarly for :hyperfiddle.post/markdown and :hyperfiddle/datomic-query.
As the person mixing them together into a github issue app, you might need to code a few little Reagent expressions if you don't like the default view. Perhaps there is a renderer for :dustingetz.todo/active-todos. There are probably also hyperlinks to related ideas like ::finished-todos and ::all-todos.
None of this requires any schema refactoring or model refactoring. You just pick the ontologies which offer the semantics you want, insert some data, point Hyperfiddle at it and it just works. When we say Hyperfiddle is a semantic web framework, this is what we mean.
This functionality is under active development and will hopefully land a first pass before Q2. It is still early design phase, so hopefully I haven't oversold the idea.