The flexibility of datalog in a fluid UI. Hummi stores everything in a database. Hummi enables user modelling.
A collection of attributes with associated values.
Like a row in a table in most databases, and like a map datastructure.
Attribute | Value |
---|---|
person/email | tim@hummi.com |
person/name | Tim |
person/hair | red |
person/likes | chocolate, coffee, hummingbirds |
Must have an id attribute nominated.
The id is necessary to determine the entity type.
In this case email
is the id.
Id can be auto generated or user supplied.
All other attributes are optional unless user specified as required.
Notice that attributes can have multiple values associated with them.
Attributes and types that describe how entities relate, and what values are allowable.
Similar to Datomic/Datascript but with some enforced conventions.
Attributes are qualified keys with a namespace that matches the entity type, and a name that describes the value to associate with it.
Like a column name in most databases, or a key in a map datastructure.
Example: person/email
A namespace. The schema maintains an index of entity type to the attributes that belong to that namespace. Like a table name.
Example: person
One of string
, number
, date
, uuid
, relation
.
May additionally be flagged as id
, unique
, one
, many
, or required
.
Like a column type in most databases.
Example: string required
Queries as patterns that look like what you are searching for.
Typical query build:
What groups exist in my organization based on shared calendar events?
What’s the average meeting load on my team?
team – person – availability
Visualizing: For n <= 20, separate line for each for n > 20, bands? distributions? distribution over time (these are just quantile bands?)?
Who is spending too much time in meetings?
What meetings could be deleted?
How much time is available for my project? (Sans leave/holidays/meetings)