Roadmap & Wish List

The Following are Ideas for Expanding on the Basic EKB, Some are in Process, Some are just ideas.  This list is not ordered and is certainly big task to fully complete, but it provides a vision of where we would like to go.

Thoughts on Priority and Approach Is Solicited

Semantic Mapping & Linking

• Goal
  • Provide the core capability to map between different ontologies representing the same things using different vocabularies and structures
  • Provide the capability to project "views" and "viewpoints" of these vocabularies based on the needs and preference of particular kinds of stakeholders. Be able to map to different terminology, data structures and visualizations
  • Provide the capability to make links between architectures "sourced" from these different vocabularies and query/analyze across the entire KB in any viewpoint
• Capability
  • Define how various forms of expression, configurations, shared concept ontologies and resources are related using mapping and linking
  • Provide mapping technology, probably built on rules, capable of providing the connections between these different forms of expression, viewpoints, configurations and shared concept ontologies
  • Make concept mapping something anyone can do
  • Integrate mapping, configurations, shared concepts and mapping into the EKB server environment

Views and Viewpoints

• Define the concepts of views and viewpoints
• Define how data structures in support of viewpoints relates to ontologies without specific structure
• Support structural views that map to "traditional" XML
• Create tooling that provides a simple to use web based interface for a view with various options to visualize the view data
• Provide "default" user interfaces based on a simple structural definition of a viewpoint. Allow the user interface to then be customized based on the users configuration. Provide for "plugins" that enhance the users experience
• Make the UI cool, effective and fun to use

Categorization and Context

• Be able to categorize and understand the context of information in the EKB
• Be able to categorize or contextualize anything across any number of dimensions
• Be able to relate categories and context to configurations and viewpoints
• Use the "publisher's" resource ID and storage hierarchy as one context, but not the only one
• Be able to browse resources by categories and context

Shared Concept Ontologies

• To avoid point-point mapping, provide "hub" ontologies that normalize like concepts between different vocabularies and data structures represented in RDF
• Provide LOD links between the shared concept and external vocabulary specific representations of the same concepts. Be able to understand when different resources represent the same thing in different ways.
• Build tooling to map external (non normalized) models into and out of these hubs
• Provide tools that are able to browse, search and analyze models that have been combined in a configuration through the shared concept hubs
• Include concepts for
  • Information, Services, Processes, Rules, Goals, Resources, Context, Security, Metadata, Etc.
• Consider existing ontologies (such as SKOS) as candidates for hubs.
• Understand where there will be different representations of information about the same real-world thing that may be in different forms of expression and sourced from different authorities. Be able to manage and analyze these differing opinions about the same thing in a configuration.
• Define a UML profile in which do manage the shared concepts

Grounding in Vocabularies

• Goal
  • To be able to use existing resources that define terms and concepts as the "grounding point" for models
  • Be able to relate independently conceived models using these grounding points
  • Use these as or to define shared concepts
• Capability
  • Be able to use Wordnet, DBPedia and similar resources as existing shared concept grounding points
  • Instead of "typing labels" make it possible to use these existing identified concepts as the names of elements
  • Provide the capability to register and share new identified concepts
  • Provide the capability to make composite concepts, essentially phrases, out of simpler ones

Provenance and Versioning

• Track the provenance of all information in the EKB
• Track the versions of all information in the EKB and be able to relate versions to specific change made for specific reasons by specific people
• For each "fact" (triple or small set of triples), be able to understand the history and provenience of that fact even as the facts are seen through various queries, configurations, views and context.
• Differentiate information for which the EKB is the system of record and information "owned" elsewhere
• Initially, allow for information edits where the EKB is the system of record
• Ultimately, be able to modify external information and synchronize it back to the external system of record automatically and with change control
• Be able to accept and understand where different authorities will have different and sometimes conflicting information about the same thing. Be able to analyze these differences and similarities.
• Provide correlation of statements in the model with external structured and unstructured resources

Information Update

• Provide the capability to update the knowledge base from web based views
• Make sure that the updated information is compliant with the constraints of the defined knowledge base
• Update information in resources based on the users configuration
• Manage information where the EKB is the system of record for the data
• Where the WKB is not the system of record, synchronize data back into the source artifacts

Information Appliance

• Make it very easy to create new data formats in the EKB. It should easier than creating a spread sheet
• Be able to use a default UI or enhanced UI to manage both tables and forms using this information
• Provide the capability to "ground" the information in shared concepts so that is linkable with other data in the EKB
• Provide simple query and reporting for the information appliance that can access both the users data as well as any data in the EKB

Social Architecture

• Create a wiki-like environment where stakeholders can work as a community to define their architectures
• Provide for "approved" spaces as well as those that are more open
• Make it easy to find and understand an architectural concept. Show information about that concept that is a projection of the underlying concepts
• Make it easy to comment on as well as update the architectural content.
• Use the architectural wiki as a basis for a community of interest to define common concepts, terms, data, processes, etc.
• Provide for authorities that can approve content for publication under that authority
• Integrate well with other social media
• Make it natural to use bits and pieces of other architectures when building a new one

Format Adapters

• Provide import/export capability for more data formats, including
  • DoDAF
  • FEA / Federal Segment Architectures
  • SQL
  • Language Interfaces and Data Structures
  • Knowledge Discovery Model (KDM)
  • Excel
  • Etc...
• Integrate the formats with shared concepts

Architecture Validation

• Provide the capability to express a set of rules to validate a complex architectural configuration
• Provide tooling that evaluates a configuration for compliance with this set of rules
• Provide tools that are able to query, track and report on compliance levels

Model Server

• Besides the current "file oriented" SVN interface to populate the EKB, provide an API for managing models that is practical as the back end to viewpoint specific tooling, such as UML, BPMN or OWL tools
• Provide versions of that API for various technologies, including Java, PHP and Python.
• Support the Eclipse EMF API such that existing eclipse tooling can utilize the EKB without change

Executable Models

Where models represent executable systems, provide a dynamic engine that is able to execute the models as represented in shared concepts
Provide external integration into the runtime system by way of standard WSDL and REST interfaces as well as data query. Provide for plug-in capabilities such that anything expressible in external languages, such as Java, can be added to the runtime system and called from the executing models
Utilize process/workflow models to direct the workflow though the system and system user interface
Model Conversion
Provide the capability to map between external standards and file formats
Use a sync/merge method to be able to either create or update artifacts in these external forms
Allow for modeling styles to effect how concepts are "lifted" from shared concepts to viewpoint specific ones
Track the versions of each artifact
Optionally, create default diagrams and other derivative information when creating or updating external formats
Examples
UML<>BPMN, UML<>OWL, BPMN<>SBVR, UML<>ER, OWL<>ER