Archives: Templates

Introduction to KnowledgeScope

The KnowledgeScope template is an innovative QualiWare Lifecycle Manager (QLM) tool designed to configure the Generative QualiAI. It is structured to streamline the process of creating intelligent and context-aware response diagrams. By leveraging the KnowledgeScope, businesses can harness the power of AI to generate diagrams that are not only accurate but also tailored to the specific nuances of their operations.

Key Features:

• Configurable Sections: The KnowledgeScope has configurable sections, such as AIKnowledgeScope, Context, Prompting, and Response, which allow you to determine the content of the diagrams created with the AI.
• AI-Driven Diagram Generation: Leverages QualiWare’s AI capabilities to produce diagrams informed by the context and prompting provided.

Section Details

KnowledgeScope

This primary section offers a succinct overview of the template’s purpose, along with a business definition and a selection of example diagrams for reference.

• Short Description: Concisely articulates the purpose of the KnowledgeScope.
• Business Definition: Provides a broad context of the business or a specific business space, if detailed in the definition.
• Example Diagram List: A curated list (recommended to be 1 or 2) of diagrams from your repository which exemplify the desired outcome, aiding the AI in context understanding.

Context

The Context section is the backbone of the template, influencing the AI’s understanding and generation process.

• Context Dropdown Menu: Offers four methods to establish context for content generation:
  • Current Selected Object: Targets the object currently selected in the web-modeler.
  • Current Diagram: Utilizes the open diagram in the current tab.
  • Select from List: Employs the selected context from the “Link Context” function.
  • Context Undefined: Provides flexibility for open context definition via text input or object selection.
• Context Templates Text Field: Lists available templates serving as potential context sources for the KnowledgeScope.
• Knowledge Structure: Comprises two subfields—Ontology and Root Definition
  • Ontology: This field is dedicated to defining the ontology that governs the data to be accessed from the Context Templates. Users should link to a pre-defined ontology, using the template “OntologyDiagram:owl” in QualiWare. This format helps the AI understand what data is relevant and should be considered during the generation process. For example, if using the BusinessProcess template, the Ontology field should point to an ontology diagram that outlines the necessary data to be accessed from the BusinessProcess context.
  • Ontology Example: ‘BusinessProcess’ The accompanying image illustrates an ontology with ‘BusinessProcess’ as the root. Use this as a guide to link your context templates to your ontology. Proper linkage ensures that AI-generated content aligns with your business framework.
  • Root Definition: Root definition is crucial as it marks the starting point for the AI’s data extraction from the ontology. When multiple context templates are used, there must be a corresponding root for each, and all roots should be contained within the same diagram. This ensures that the AI has a clear entry point to begin its contextual data interpretation for each template. The roots collectively form a map of data points that the AI uses to extract information relevant to the generation of the new content.

Prompting

This section allows users to input additional knowledge characteristics and set the randomness level of AI responses.

• Additional Knowledge Characteristics: This section directs the AI in creating diagrams that align with specific organizational standards. For clarity and precision, input concise directives. For example:
  • Diagram Initiation: “Begin and end WorkFlowDiagrams with a Business Event.”
  • Naming Conventions: “Use concise, descriptive naming for all symbols.”

  These instructions shape the AI’s output, ensuring it meets your defined criteria and maintains consistency with your organization’s practices.

• Randomness (Temperature): A dropdown to adjust the AI’s creativity level, with a recommended default of 0.3 for diagram creation.
• Knowledge Prompts: A collection of pre-defined AI query templates, that you have created, used to standardize rules or commands across various KnowledgeScopes.

Template Naming Conventions

Proper naming of templates is critical for ensuring seamless functionality within the KnowledgeScope. Adhering to QualiWare’s naming conventions allows the AI to accurately recognize and apply the correct templates during diagram generation. Here’s what to keep in mind:

• Exact Match Requirement: Name all templates precisely as they appear in QualiWare, with correct capitalization and spacing. For example, use “WorkFlowDiagram,” not “workflow diagram” or “Work Flow Diagram.”
• Consistency Is Key: Uniform naming across all sections of KnowledgeScope ensures that the AI correctly interprets and utilizes the templates.
• Verification: Double-check template names for typos or discrepancies before finalizing the KnowledgeScope configuration.

Accurate template naming enables the AI to understand and execute your instructions effectively, ensuring the generated diagrams meet your exact specifications.

Response

The final section defines the desired outcome from the AI’s generation process.

• Response Type: Specifies the format of the AI’s output, e.g., “Diagram with objects.”
• Response Diagram Type: Indicates the template to be used for the response diagram, e.g., “WorkFlowDiagram,” with strict adherence to QualiWare naming conventions.
• Response Symbols & Connection Types: Defines the elements to be used within the generated diagram.
• Response Diagram Layout: Determines the presentation style of the generated diagram.
• Response Template Descriptions: Provides a detailed description of the diagram and its components, with more emphasis on lesser-known templates.
• Response Ontology: An ontology that guides the appearance and structure of the response diagram.

Utilization Guide

This template is structured for ease of use, guiding users through a step-by-step configuration for the Generative QualiAI. For precise diagram generation, it is recommended to provide detailed and accurate information in each section, aligning closely with your business’s operational context and requirements.

Tree signifies that an element is a component of another element of the same type. This highlights hierarchical relationships, where a dominant element encompasses others as its constituent parts.

Examples:

• Organisations manifesting as a tree of roles, teams, and departments.
• Capabilities branching into various sub-capabilities.
• Product portfolios dividing into categories, components, and individual products.
• Brand portfolios distinguishing between corporate, product, and special edition brands.
• Goals arranged hierarchically from strategic to tactical and operational outcomes.

Applications: The ‘Tree’ structure aids in:

• Breaking down an element into its nuanced sub-elements.
• Denoting that a smaller entity forms part of a larger one.

In a nutshell, the ‘Tree’ concept in EDGY represents structured hierarchy and part-whole relationships within an enterprise.

The Tree is a part of the EDGY language created by the Intersection Group.

Flow signifies how one element influences another by transmitting objects. It’s the backbone of an enterprise, highlighting how interconnected parts collectively produce results unattainable individually.

Examples:

• Teams relying on information from others.
• Monetary transactions between businesses.
• Data shifts between software systems.
• Movement in supply chains.
• The energy in team collaborations.
• Public enterprise goals tied to budgets.

Applications: ‘Flow’ aids in:

• Facilitating communication.
• Optimizing processes.
• Mapping task sequences.
• Identifying inter-organizational flows.

In essence, ‘Flow’ is the dynamic force driving collaborative efficiency in an enterprise.

The Flow is a part of the EDGY language created by the Intersection Group.

Link is a fundamental concept denoting a meaningful structural association between two elements. Far from being a mere connection, a link elucidates the relationship between these elements, illuminating its relevance within the broader scope of the enterprise.

Types and Facets of Core Links: EDGY modeling boasts a rich lexicon with twenty-four pre-defined types of links. This variety allows for a nuanced expression of relationships between design elements, ensuring both clarity and specificity. These links have been categorized into several facets:

1. Identity:
   • Story contextualizes purpose.
   • Content expresses purpose.
   • Content conveys story.
2. Experience:
   • Task is part of journey.
   • Task utilizes channel.
   • Journey traverses channel.
3. Architecture:
   • Capability requires asset.
   • Process realizes capability.
   • Process requires asset.

… and so on, for each facet.

By utilizing these core links, co-designers from diverse disciplines can engage in a richer dialogue, enabling them to integrate their specialized designs more effectively across their respective fields.

The Link is a part of the EDGY language created by the Intersection Group.

PackageMerge is a template in a Class Diagram that represents a relationship between two packages, indicating that one package (the receiving package) is merging with another package (the merged package). PackageMerge is used to combine or merge the contents of the two packages, integrating their elements in a way that creates a more coherent or simplified model. The receiving package effectively absorbs the contents of the merged package, including its classes, interfaces, datatypes, and other elements.

The PackageMerge relationship helps to manage complexity and maintainability by allowing you to refactor or reorganize the model as it evolves. By merging related packages, you can simplify the structure and reduce potential redundancies or inconsistencies.

Example: In a Class Diagram for a system that manages a hotel booking platform, you might initially have two separate packages: “GuestManagement” and “ReservationManagement”. The “GuestManagement” package contains classes like “Guest” and “GuestPreferences”, while the “ReservationManagement” package includes classes like “Reservation”, “Room”, and “Booking”. As the system evolves, you may decide to consolidate these related packages into a single, cohesive package called “BookingManagement”. You can use a PackageMerge relationship to merge the contents of the “GuestManagement” and “ReservationManagement” packages into the “BookingManagement” package. This simplifies the model and makes it easier to understand and maintain.