Skip to content

AI DSL Ontology requirements

Jump to bottom
kabir edited this page Feb 25, 2021 · 8 revisions

High level requirements

Extendability discuss

The ontology data types and AI task types should be extendable in the sense that individual service providers / users should be able to extend existing ontologies, create new types and tasks and make them available to the network. AI-DSL should be able to ingest these new types / tasks and immediately be able to do the type-checking job. The ontology of types / tasks has to be able to evolve. However, the ontology will define small kernel / vocabulary of globally accessible grounded types' which will be built-in into the platform at the deeper level and will require voting / global consensus to be changed/extended.

It seems therefore that it is best to break the AI-DSL Ontology into two level:

  1. The globally accessible vocabulary/root ontology of grounded types. This vocabulary can be seen as immutable (in short and medium term) kernel. It should be extendible in the long term, but the mechanisms of changing and extending it will be quite complex, most probably involving theorectical considerations and/or a strict procedures of reaching global consensus within the whole platform (a sort of voting);
  2. A decentralized ontology of types and tasks which each are based (i.e. type-dependent) on the root ontology/vocabulary, but can be extended in a decentralized manner -- in the sense that each agent in the platfrom will be able to define, use and share derived types and task definitions at its own discretion without the need of global consensus.

Competing versions and consensus discuss

We want both consistency (for enabling deterministic type checking -- as much as it is possible) and flexibility (for enabling adaptation and support for innovation). This will be achieved by enforcing different restrictions for competing versions and consensus reaching on the two levels of ontologoy descrbed above:

  1. The globally accessible vocabulary / root ontology of grounded types will not allow for competing versions. In the sense, this level will be the true ontology, representable by a one and unique DAG in the network;
  2. All other types and task definitions within the platform will be required to be derived from the root ontology (if they will want to be used for interaction with other agents); However, the platform will not restrict the number of competing versions or global consensus mechanisms of types and task descriptions on this level.

Furthermore, the ontology and the AI-DSL logic should allow for some variant of 'soft matching' which would allow to find the type / service that does not satisfy all requirements exactly, but comes as closely as available in the platform.

Code-level / service-level APIs discuss

It is important that the ontology is readable / writable by different components of the SNet platform, at least AI-DSL engine itself and each SNET service separately. This is needed because some of the required descriptors of an AI service will have to be dynamically calculated at the time of calling a service and will depend on the immediate context (e.g. price of service, a machine on which it is running, possibly reputation score, etc.). It is not clear at this point how much of this functionality will be possible (and practical) to implement on Idris. Even it if is possible to implement all AI-DSL purely on Idris, it will have to interface with the world, input from network and mutable states -- operations that may fail in run-time no matter how careful type checking is done during compile time1.

Defining and maintainint code-level and service-level APIs will first of all enable the interfacing SingularityNET agents to AI-DSL.

Key AI Agents properties discuss

Initially, the description of each AI service should include at least these properties:

  • Input and output data structures and types
  • Financial cost of service
  • Time of computation
  • Computational resource cost
  • Quality of results

Most probably it is possible to express and reason about this data with Idris. It is clear however, that in order to enable interaction with SingularityNET agents (and NuNet adapters) (see appropriate section, all above properties have to be made accessible outside Idris and therefore supported by the code-level / service-level APIs which, in turn will depend on data structures and infrastructure (see section).

Footnotes

[1] : Resource-dependent Algebraic Effects, Edwin Brady In proceedings of TFP 2014

Clone this wiki locally