doknil/paradigm

Doknil is based on:

• subject
• hierarchical role
• optional hierarchical of part
• optional contexts specifying the time-frame, or the branch, or the transaction, etc..
• standard derivation rules according the context, and hieararchical role and parts

The scope of Doknil is not to be a complete graph database for representing all informations about objects. Doknil is used as an initial and quick way to store information. It is a sort of tag-system and directory classification system on steroids. The user search information quickly inside Doknil, and then he can use better queries later.

Doknil can be used for clasifying: emails; documents; files; part of code; relationship between a source code, its compiled file and so on;

Transactions

A Transaction specify: who, when, what, why. They are hierarchical tasks.

Bulk off-line updates

Some Doknil classifications of documents can be completed in bulk, off-line from AG code analyzing documents.

Types vs Roles

Doknil uses the subject isa role, but isa links entities (i.e. type instances) with roles, and it is not used for types. So this is wrong magnolia isa plant, because magnolia is a type of plant. Instead this is correct ref12 isa plant/magnolia, because it specifies the type/role of a concrete entity.

Facts with multiple properties

Facts with multiple properties can be represented by entities with Dok properties.

$f1 isa flight

set $f1.from: $London
set $f1.to: $Paris

MAYBE Metaclass

Facts can be stratified by meta levels.

These facts are at the metalevel of schema description: plant isa type. magnolia isa type. magnolia isa subtype of plant.

This fact is at the level of entities: $ref12 isa plant/magnolia

TODO checktech/conceptbase

Fuzzylogic

Fuzzy facts, if supported, are not managed as a context, but with an additional attribute.

Schema

The subject and role relationship is also a guideline for creating the schema.

$smith isa employee
$b isa bank-account of $smith

$actor1 isa actor of $film1

The inverse relationship is not feasible in Dokmelody

$film1 has-actor $actor1

The role enforces subject with an active role.

Null management

null can be used for identifying: unknown value; not-applicable value; default-value; etc…

Contexts

If one add a new cntx to schema, he had to specify also the default value to associate to the new context, for all objects. It can be a to-specify value, in case the value is mandatory and there is no known value to use.

Tags

We can tags films to watch and review.

$film1 isa film/to-review of task/$review2