Thingbase - HackMD

# Thingbase - [Thingsbase Google Doc](https://docs.google.com/document/d/1dgee3Mo8Jt78iwomo2ne0mgac1XZSF8WDzkei3i11lo/edit#) INTENT: To provide a simple widget which will make new records in a graph database. A minimum of typing / tagging / binary object dragging will be required to make it possible to characterise a referent which can be recorded such that it will be connected into a meaning graph. Use of two tagging fields: - Out-tags - associating other referents as context(s) to which the current referent contributes meaning, and - In-Tags - associating other referents as contributing meaning to the current referent, - will allow representations of the graph to be ordered according to scope. - Referents with no Out-tag in any set of records under consideration will be considered to have maximum scope. Referents with Out-tags of only maximum scope will be ranked second, and so on. The most immediately desired result of such a ranking will be the presentation of referents in a ‘semi-lattice’ graph, which should be ‘live’ - with all elements of the visualisation linked to the relevant data: ## USE-CASES Any domain where coherent meaning requires mapping of arbitrary associations - where reductivism in the service of simplistic structure would be dangerous / sub-optimal. In other words, any complex domain. In other words, most non-trivial contexts. ## DESCRIPTIVE SCHEMA: NB: This is deemed to be the minimal schema to achieve the intent. If this is achieved, then it can serve as a base on which to build many useful things. Argument maps, complex system maps, pattern languages... There are REFERENTS, which have REFERENT-NAMES (unique - act as primary key), and can have an associated BINARY-BLOB. REFERENTS are INSTANCES of at least one TYPE. There are various TYPES, which are CHARACTERISED by particular sets of ATTRIBUTES. REFERENTS which have been CHARACTERISED with a TYPE are considered ( as concerns that TYPE) to be SKETCHY, unless they are DEFINED (they have the minimum subset of ATTRIBUTES required). REFERENTS may be OUT-TAGGED with other REFERENT-NAMES as CONTEXTS within which the REFERENT contributes meaning. OUT-TAG instances may have an associated TEXT-NOTE. REFERENTS may be IN-TAGGED with other REFERENT-NAMES as CONTRIBUTORS of meaning to the REFERENT . IN-TAG instances may have an associated TEXT-NOTE. NB: Tags which would create circular references are permitted where these would not make it impossible to assign scope-rank - and thus impossible to produce the semi-lattice graph. In such cases, it should be assumed that the tagging is important, and the circularity should be resolved by cloning one referent, and associating the clones with an appropriate tag relationship (how to choose which one?). TYPES Use-case/ domain specific Types will likely be used. It is considered that this is not required; that the fullest value of this data-structure will be realised by including a sufficiently wide set of Types to encompass the full gamut of experience. However, it is acknowledged that technical constraints will apply - and further, that hubris should be avoided. Here is a list of types which could be sufficient for a typical project-related domain. List of TYPES (attributes required for ‘DEFINED’ status are indicated with a *. Note that these are deliberately minimal - where practical, the REFERENT-NAME, which is required to be unique should be enough. User(s) can add/amend/delete attribute content as required during the lifetime of the graph.) EVENTS These may have: *(DATE -or- DATE-RANGE) TIME -or- TIME-RANGE DESCRIPTION/NOTE (if not present, REFERENT-NAME will be used in output) LINKS These may have: *URL DESCRIPTION/NOTE (if not present, REFERENT-NAME will be used in output) PEOPLE These may have: *FIRST NAME LAST NAME ORG-ASSOCIATION (plural) CONTACT DETAILS BIO DESCRIPTION/NOTE (if not present, REFERENT-NAME will be used in output) ORGS These may have: CONTACT DETAILS ORGANISATION DETAILS DESCRIPTION/NOTE (if not present, REFERENT-NAME will be used in output) MEDIA These may have: *BINARY-BLOB MEDIA-TYPE MEDIA METADATA This would be a long list of possibles dependent upon Media-Type DESCRIPTION/NOTE (if not present, REFERENT-NAME will be used in output)