Ontology Document Generation for REST API Consistency

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Current APIs lack consistency in information modeling, leading to disparities in data formats and processing rules, making it impossible to create a generic client that can access all APIs using a common set of processing rules, and resulting in inefficient and error-prone interface development.

Innovation Solution

A computer-implemented method generates an ontology document using a domain-independent data structure and operation structure, which breaks down the concept of ontology into domain-dependent and domain-independent structures, ensuring consistency across domains and allowing for the creation of software artefacts like APIs and interface specifications that are compliant with the REST architectural style.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If a domain-specific language and data format are customized for each API, then the API can be tailored to specific domain requirements, but consistency across different APIs is lost and a generic client cannot be created

Engineering Contradiction:
Improvedomain-specific customizationVSAvoidgeneric client creation
Core Design Contradiction:
Adaptability or versatilityVSEase of operation

Solution Approach 1:

The ontology is segmented into domain-independent components (data structure, operation structure, HTTP semantics) and domain-dependent components (specific language, data format). This segmentation allows each layer to serve its purpose: domain-specific customization at the application level while maintaining consistency through standardized underlying structures.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

A domain-independent ontology structure acts as an intermediary layer between domain-specific APIs and generic clients. This intermediary provides standardized processing rules and data formats that enable generic clients to interact with diverse domain-specific APIs without requiring custom code for each API.

Inventive Principle:
Principle #24Intermediary (Mediator)

2Reliability

If custom code is written for each domain and data format, then specific processing requirements are met, but development efficiency decreases and error-proneness increases

Engineering Contradiction:
Improveprocessing requirements fulfillmentVSAvoiddevelopment efficiency
Core Design Contradiction:
ReliabilityVSProductivity

Solution Approach 1:

The domain-independent ontology structure provides universal processing rules that can be applied across multiple domains and data formats. This universality enables a single generic client implementation to handle various domain-specific APIs, significantly improving development efficiency while maintaining reliability through consistent processing logic.

Inventive Principle:
Principle #6Universality (Multi-functionality)

Solution Approach 2:

The system changes parameters from domain-specific customization at every level to standardized parameters at the ontology level, with only domain-specific semantics varying. This parameter standardization allows reusable toolkits and generic clients to operate across different domains while meeting specific processing requirements through configuration rather than custom code.

Inventive Principle:
Principle #35Parameter changes

3Ease of operation

If RESTful principles are fully implemented with domain-independent structures, then consistency and reusability improve, but flexibility in domain-specific implementation is reduced

Engineering Contradiction:
Improveinterface consistencyVSAvoiddomain-specific flexibility
Core Design Contradiction:
Ease of operationVSAdaptability or versatility

Solution Approach 1:

The ontology structure applies local quality by maintaining domain-independent standardized structures at the core level while allowing domain-specific languages and data formats at the application level. This enables RESTful principles to ensure interface consistency where needed, while preserving domain-specific flexibility where required.

Inventive Principle:
Principle #3Local quality

Data Source

PatentUS8898103B2Method and device for generating an ontology document
Publication Date: 2014.11.25 FUJITSU LTD
  • US8898103B2 patent drawing
  • US8898103B2 patent drawing
  • US8898103B2 patent drawing

AI summary

A computer-implemented method is provided for generating an ontology document, the method comprising inputting a domain description including information about items in the domain and relationships between the items; accessing a data structure and an operation structure, wherein the data structure is a domain-independent model of items and relationships between items, the data structure comprising at least progenitor items each able to contain only progeny items created by the progenitor item as a consequence of the progenitor item accepting an operation from the operation structure invoked against it, the operation structure also being domain-independent; and applying the data structure and the operation structure to the domain description to generate an ontology document for use in producing a software artifact.