DIGIT is a specification-driven open-source technology platform that leverages the capabilities of microservice design to promote responsive and agile solutions. This site covers a microscopic view of the standards and specifications that enable the co-creation of secure, agile, interoperable, and manageable solutions as part of the DIGIT platform.

Objectives

The objective of this site is to provide specifications for DIGIT architecture as well as for the implementation of specific DIGIT products.

The site offers -

• A single point of reference for DIGIT implementation and integration specification

• Act as a guideline for partners and co-creators on key details to consider

• API interaction details

• Key benchmarks to follow

Scope

The site describes the DIGIT technology specification in the context to -

• Common Service Specs

• Domain Service Specs

Analytics APIs

API specs to configure dashboard visualisations and fetch data for the configured visualisations.

Billing APIs

Manage demand, bill and amendments

Access Control APIs

API specs to map actions to roles.

Encryption Service

API specs to encrypt, decrypt, sign and verify data.

Employee APIs

APIs available from Employee Information System for employee services to -

• create statewide standardized database of the employee to streamline processes related to personnel management

• increase transparency for higher management for efficient resource planning

• integrate with rainmaker modules for security, authentication and workflow handling

• establish KPIs for employees and generate reports

DSS Ingest APIs

API specs to manage and facilitate data ingestion for decision support systems.

Filestore APIs

API contracts to manage files e.g. images, PDF, XLS etc

Effective co-creation and partnerships in developing digital public goods are based on solid frameworks and principles that define the rules of co-creation. The DIGIT platform is designed using open-source standards that allow other stakeholders in the ecosystem to contribute and build innovative governance solutions.

The published DIGIT specifications and open standards principles help in identifying and explaining the module taxonomies, data modelling approach and API data interactions. This section provides a detailed insight into the DIGIT platform specifications and open standards approach in general.

1. Taxonomy Specifications

2. Data Modelling Specifications

3. API Data Interaction Specifications

Taxonomy Specifications

The past couple of decades has seen an increasing thrust from governments to build digital infrastructures that are scalable and follow open standards. Frameworks, institutional mechanisms, and standards are necessary to bring comprehensiveness to the eGovernance initiatives. It can also help drive efficiencies that enable large-scale transformations. These frameworks and standards are also crucial for bringing us closer to building our technological sovereignty.

There is an established need for standardized knowledge systems that can aid in developing sustainable digital solutions. To build standards that can provide context and boundary to an otherwise fragmented knowledge base of ‘Urban Governance,’ Taxonomies and Ontologies have been identified as essential tools. They are integral to the standards that evolve.

Approach

Creating taxonomies is foundational in any knowledge system, and this document attempts to be a repository for standardized nomenclature and classifications in different e-governance application domains. Taxonomies help build robust frameworks and guidelines that support specific operations in context. It aids them in creating workable solutions down the line that can be adopted across different ULB jurisdictions across India.

The taxonomies defined as part of DIGIT specifications establish key principles in the context to various elements linked to the specific module. And, this knowledge is essential to bring in a uniform understanding of the domain and its diverse components.

Scope

The taxonomy is developed to meet the practical need to carve out a harmonized view of different elements of the module. It tries to capture the most important entities, their properties, categories, subcategories, parameters, and specifications within this domain as well as other associated areas.

Capturing abstract knowledge across a domain and rendering a uniform perspective of this knowledge is the core challenge in the development of knowledge representation tools like taxonomies and ontologies. Taking this into consideration, a conceptual framework has been followed, which helped in enforcing a systematic approach to building the taxonomies.

This framework follows a bottom-up approach and allows inductive inferencing while developing these knowledge models. The framework has seven broad components, and they are elucidated using an example of building a taxonomy for college education in India.

Domain – A domain outlines the scope of the knowledge area around which the taxonomies and ontologies are to be defined. In our example, the Indian Education System can be marked as the domain.

Sub Domain- A Sub Domain denotes a subset of the knowledge area. It narrows down the scope of the knowledge area and helps in establishing a clear context. A domain may consist of more than one sub-domain, and these sub-domains can be overlapping or mutually exclusive. For instance, the domain of the Indian Education System can consist of several sub-domains like - Higher Education Systems, Primary Education, Elementary Education, Integrated Child Welfare Schemes (Anganwadis), etc. To analyze college education in India narrowing it down to the subdomain of the Higher Education System, will bring more focus.

Entity- Entities in a domain define the nouns in that knowledge area. They are the essential building blocks in any knowledge model. While building taxonomies and ontologies, identification of the key entities and defining them is a critical step. In a college taxonomy, Infrastructure, Learning Aids, Teaching Staff, Non-Teaching Staff, Governing Bodies, Pedagogy, and Academic Subjects are examples of a few entities that surface. Each of these entities does not stand in isolation and is usually supplemented with peripheral associations and terms. This discovery process is iterative and usually spawns a universal terminology for a domain.

Properties - The Entities that are associated with a Domain/Sub Domain are analyzed to identify the properties, processes, services and other aspects related to them. In the example above, if we pick an Entity like Teaching Staff, the associated properties could be Qualifications, Subjects, No of years of experience etc. This exercise helps in bringing clarity about the entities and help in categorizing and identifying parameters and specifications.

Categories- The Entities and their properties will form logical clusters which can be carved into categories and sub-categories. The higher or more generic category subsumes the sub-categories within it leading to hierarchical relations. When organized together as a whole they yield taxonomies. With the example above there could be many categories around each of these entities.

Values- These are the most granular units within a taxonomy. They are usually the assignments in the last sub-category within a branch of a taxonomy. In the current example, consider analyzing the entity - Learning Aids; as we build the taxonomies around it, the possible values that can evolve could be visual aids, recorded audio, textbooks, and so on.

Parameters and Specifications– These do not form part of the taxonomy but carry essential information. This information may be used to execute a process or provide a service. For example, student admissions can have specifications like age, address etc.

Design

To ensure this taxonomy fits the needs of interested stakeholders the following principles have been followed in designing it. The principles are explained in context with the help of inferences from the Property Tax module for illustration.

Usable: Property Tax is predominantly a local tax falling under the jurisdiction of State or ULBs and is governed by State Acts. The local options regarding the tax will be heterogeneous. To fit the multivariate property tax systems in India the taxonomy has been designed to be coarse-grained, light-weight and minimalistic.

Evolvable: The taxonomy is designed to evolve over a period of time thereby adapting to changing needs and emerging technologies. For example, “Collection Channels'' for Property Tax are defined to accommodate any future advancements in the digital payments space.

Modular: The categorizations in the taxonomy are designed modularly, yet they function together as a whole. They are independent and self-contained and may be combined and configured with similar units to achieve a different outcome. These categorizations can be unbundled into multiple simple categorizations. They can be further re-bundled in a modular manner to suit disparate contexts. For example, the Property “Usage” element and its sub-classifications can be easily reapplied in the context of any Building Plan Approval System.

Extendible: The taxonomy is designed to be exhaustive and the elements of Property Tax are positioned in a hierarchy that can accommodate both horizontal and vertical additions. This leaves room for wider adoption and innovation to suit the contexts of any ecosystem. Also as stated earlier in the document the end goal is to build a knowledge practice that supports Open Standards, and taxonomy is an entry point. As it evolves it will be used as a basis to build ontologies around the Property Tax domain.

Open: The taxonomy has been designed to be ‘open’ to allow publishing under the most unrestricted licenses to enable wider ecosystem participation and foster innovations.

Data Modelling Specifications

The Data Model standards and specifications help in explaining the DIGIT module design specifications that further translate the conceptual rules into recommendations, requirements, and restrictions.

Approach

Data models offer a three-dimensional view of what data needs to be collected, how is the database structured, and how the data entities across segments map to one another. The principles and specifications in this section help in defining the key standards applicable across the DIGIT platform to ensure interoperability across the platform and consistency in database design.

Versioning: The design of the data models takes into consideration the fact that these will evolve with time and also allow contributions from multiple stakeholders. The version upgrades will be added to this site for reference guidelines.

Scope

The data model design and specifications are based on the guidelines listed below.

Open: In order to maintain technology and vendor neutrality, DIGIT data models -

• are published under the Creative Commons Attribution 4.0 International License

• does not assume or require the choice of any proprietary technology

• is designed and ratified through a multi-stakeholder process

• is developed/reviewed/adopted by a group of experts through a consensus-based process

Evolvable: To adapt to changing needs over time, data models -

• Are versioned with backward compatibility of at least up to 1 major version.

• Is protocol-agnostic to facilitate innovation in protocols and support solution use cases over multiple protocols (e.g. governance application over chat interfaces). In other words, they follow The Rule of Least Power. In order to achieve this, data models carry all the necessary information –

  • request metadata e.g. authentication token, device information, signatures

  • response metadata e.g. response signatures, processing status, correlations ids

  • error data e.g. error codes, messages etc.

• in its own structures, rather than depending on protocol-specific fields/headers to carry such information.

Extendable: Given the diversity of India’s urban systems, it is important to ensure that standards do not limit the ability of solution providers to develop solutions that meet local needs. Further to enable innovation, standards should not be restrictive in their specification and application. Thus standards need to be extendable to enable ecosystem actors to innovate and build locally relevant solutions. Therefore, data models -

• extend from existing international/national standards like National Municipal Accounting Manual (NMAM) wherever possible

• allow adding optional business extension elements

• such extension elements are clearly documented in the same manner as base models and APIs and made available on a public repository

Minimalistic: To enable ecosystem actors to easily adopt standards while empowering them to innovate, data models -

• contain minimal mandatory fields in data models

• require only the most fundamental API operations to enable faster compliance while fulfilling needed functional requirements. The consistent pattern in API operations on various entities makes them simple to adopt.

• avoid including attributes/APIs needed for specific solutions that are not yet known to be applicable to wider solutions.

Balance Data Privacy with Data Empowerment: To leverage the power of data while ensuring safe usage, data models -

• require minimal personally identifiable information (PII) to be collected mandatorily thereby reducing risk to PII data

• provide policy-based access control to enable the creation, modification and sharing of data as needed

• include provision for data anonymization and proxy fields for PII and other sensitive data

Provide for non-repudiability: To ensure the right attribution for the data, data models -

• declare access mechanisms for APIs

• provide digital signatures

• provide APIs for accessing data access information

Unbundled: To provide the most fundamental building blocks while ensuring minimalism, extensibility and evolvability, data models -

• limit the mandatory information in data models

Design

Given the role and significance of the DIGIT platform in building citizen-centric applications and technology-based solutions for the community, it is crucial to define the data modelling standards. Standardized data aids in interoperability, and improves accuracy while ensuring consistency.

• Data Models are broken down into simpler fundamental units (models) as far as possible. For example, a property assessment model is basically a property model and assessment model with the assessment model referring to the property model.

• Data models include a Universally Unique Identifier (UUID) field which uniquely identifies the object of the respective entity type within the respective domain. Data models require minimal mandatory fields to enable maximal inclusion. As a thumb rule, wherever unsure whether a field is absolutely required in all scenarios, it should be made optional.

• Data models extend/ reuse/ adopt international/ national models wherever available/applicable e.g. Open311 for citizen services like grievances and schema.org for general model definitions.

  1. Data models are extensible i.e. they allow a way to capture extra information that was not initially included during the model design. To achieve this: It may provide a simple map of key-value pairs. Future versions of the data model may choose to create mandatory/optional name attributes in the data models after researching the wider applicability of such fields.

  2. Data models allow for namespacing in field names to indicate the source/reason/category of the extended fields.

Dashboard Analytics Service

APIs for DSS analytics dashboard primarily consists of 2 APIs. The one which is used to get configuration based on which the dashboard is painted. The other one is the API which gets the data needed for the visualization to paint different graphs.

Collection APIs

APIs to collection revenue

Indexer Service APIs

API to enrich and push events. Events can be used for providing unified inbox, analytics etc.

Employee Inbox APIs

API specs that route applications to employee inbox assigned for action.

Payment Gateway APIs

Facilitates payments, refunds and search transaction details.

ID Generation APIs

Generates unique ID/code in the prescribed format

Master Data Management APIs

Fetch master data for specific tenants and modules.

Master Service APIs

APIs to create, update or search masters.

OTP Service APIs

Enables OTP creation, validation and search functions.

User Services APIs

Create, update and search users. Users encompass any user interacting with the system such as citizens, employees, contractors, vendors, etc.

PDF Service APIs

Generate output in PDF format and return its filestore ids.

Attendance APIs

API specs to manage the functions of an attendance register. Staff and attendees are mapped to an attendance register. The entry and exit times are logged in epoch time for an entity.

URL Shortening APIs

Shorten specific URLs and get original URLs from the shortened URLs.

Bank Account Service APIs

APIs to store and manage financial account details of entities (individuals or organizations).

Workflow Engine APIs

APIs to create new, search, initiate workflows and transition states.

Birth & Death APIs

APIs to create new birth and death applications, update existing applications, search applications and download birth and death certificates.

Building Plan Application System APIs

Stakeholders apply for building permits using the eDCR scrutiny.

Billing Calculator Service

APIs to generate three distinct types of bills for MuktaSoft - wage, purchase and supervision. The API specs here enable the calculation of bill amounts. The _estimate API performs the same calculation as _calculate but returns only temporary results. _calculate computes amounts for a bill, stores metadata about the bill and calls the expense service to create a bill.

Campaign Service APIs

Facilitates campaign management - create, update, search or schedule campaigns.

Building Plan Application System APIs

The BPA calculator is one of the services in the building plan approval system used for fee calculation and demand generation.

Campaign Delivery Service APIs

Facilitates the delivery of campaign resources to registered beneficiaries.

Estimates Service

APIs to enable create, update and search functionalities for works estimates.

eChallan System APIs

API specs to generate new challans, update existing challans, search challans, and generate demand bills for the challan amount for collection purposes.

Contract Service APIs

APIs to manage the functionalities of a Works contract.

FSM Service APIs

Apply for desludging services, update application details or search applications.

Fire NOC APIs

API specs to apply for Fire No Objection Certificates, search and update Fire No Objection Certificates.

Facility Registry

This module facilitates the maintenance of a Facility registry.

Fire NOC Calculation APIs

APIs to calculate Fire NOC fee.

Household Registry

Manage and maintain household registries.

Muster Roll Service

Attendance aggregator service that aggregates attendance for a specified period per entity. Works with Attendance module.

Land APIs

API specs to create land registry applications, update, and search applications.

National Dashboard Data Ingest APIs

Provides a way to ingest key performance metrics for modules in the National Dashboard system to facilitate a combined view of all state data on the dashboards.

Campaign Inventory Management APIs

Facilitates the maintenance and management of inventories.

Individual Registry

Maintain and manage individual registries.

Organization Service

Organization service and registry. The spec has two components.

• The organization services APIs are meant to house business logic such as workflow and/or other validations.

• The organization APIs provide access to the pure registry without any of the add-on services. Those who want to use the pure registry can do so without the requirement to use workflow or other services.

No Objection Certificate Application Registry APIs

API specs to apply for NOC, search or update NOC details, and allow users to take necessary actions on the NOC application.

Property Registry APIs

Create new properties, update or search existing properties.

Campaign Planning Service APIs

Facilitates planning of campaigns.

Product Registry

Maintain and manage product registries.

Project Management Service APIs

Facilitate the management of projects.

Property Tax Information System APIs

API specs to handle property assessment, change existing property details, change of ownership, calculate property tax, demand generation, and enable ULBs to manage properties.

Campaign Registration Service APIs

Facilitates the registration of households to campaigns.

Public Grievance Redressal APIs

Allows citizens to raise complaints, give feedback on the resolved complaints, or reopen complaints if not satisfied.

Sewerage APIs

APIs for Water & Sewerage module to create, search and update existing properties.

Stock Service APIs

Facilitates the management of stocks.

Supervision Service APIs

This facilitates the supervision of campaigns.

Sync Service APIs

Allows the sync of health campaign data for offline applications.

Trade Licence APIs

API specs for creating new trade licence applications, searching and paying for trade licences.

User Events System APIs

APIs to manage - create, update, or search events-related information.

Trade Licence Calculator APIs

API specs to calculate trade licence fees.

Vehicle Registry APIs

API specs to capture vehicle details, add new vehicles, and update and search existing vehicle details.

Water Service APIs

API specs to create, update, and search properties.

Vendor Registration APIs

API specs to register vendors for desludging operations, map vehicles to operators, search vendor details, or update existing vendor details.

Entities and Categories

This section outlines the key entities, properties and major categories associated with the Property Tax governance component. It summarizes their categorizations and sub-categorizations and values. The categorizations primarily establish hierarchical relationships that can be established and as a whole yield taxonomies around Property Tax.

The illustration above offers a consolidated view of the key components and entities defining the Property Tax system.

While building the knowledge models for Property Tax systems, it is imperative to consider entities that are interlinked with Property Tax. Property Tax is a type of Revenue charged against a property. Collections operationalize the Revenue mobilization within a ULB. Hence taxonomy for Property Tax cannot be built in a silo and needs to be accompanied by entities like Property, Revenue and Collections.

Key Terms & Definitions

Property ID

Ownership

Location

Property Composition

Property Tax

Assessment Method

Property Tax Period

Property Zone

Property Bill Constituents

Property Tax Components

Property Processes

Revenue

Type of Revenue

Account Head

Payer

Payee

Ultimate Payee

Amount Due

Collection

Collection Channel

Mode of Payment

Service Provider

Amount Collected

Appendix

Parameters and Specifications in Property Tax

Measurements

Key terms and Definitions

Appurtenant Area: Anything attached to a piece of land or building such that it becomes a part of that property, and is passed on to a new owner when the property is sold. It may be something tangible like a garage, septic system, water tank, or something abstract such as an easement or right of way.

Location

Key terms and Definitions

Address: The address of the property provides the particulars of the place as per the administrative boundaries or norms defined by the local governing body.

Geo Location: Geolocation is the identification or estimation of the real-world geographic location of the property. This refers to the latitude and longitude coordinates of a particular location where the property is located.

Digital Door Number: Property Numbers are defined using scientific methods and often assigned with QR codes for traceability and usability.

PT Calculation Methods

Key Terms & Definitions

Capital Value System: The market value of the property is the basis of estimating the taxes to be paid. This market value is determined by the government and revised annually, based on the ward in which the property is located.

Unit Area Value System: Under this system, the tax is levied on the per-unit price of the carpet area or the built-up area of the property. Municipalities like New Delhi, Bangalore, Kolkata follow this method.

Annual Rent Value: It is the amount of the property which might be let out on a yearly basis. In the case of self-occupied property used for staying by the owner, then the value is zero. In a situation where the owner is neither staying nor letting it out then also, the value is zero. The gross annual rent of the property is fixed by the municipal body which is generally higher than the actual rent received or expected rent. The municipality of Chennai and Hyderabad use this method

Payment Gateway

Payment gateway is a trusted financial intermediary which facilitates secure digital fund transfer between parties involved and keeps them informed on the status of transactions throughout the lifecycle of transactions.

Classification Tables

Property

Property Tax

Property Processes

Revenue

Collection