What's the Issue?
The ability to easily interact with the schema and edge rule files is not currently available, the end user would have to manually digest the files. The files are not easily deciphered and as they increase in size and number, we need a generic solution to provide an easier way to interact and enable understanding of the schema/edge rules files.
What must the solution provide?
- a generic interface to interact with the schema and edge information, so it can be accessed via end users and microservices
- ability to be configured with any schema given in the set formats (JSON for edge rules, OXM for schema)
- ability to easily communicate to an end user a node type’s attributes and edge rules when provided with a node type as input
- ability to define the depth (number of traversal hops) and relationship type (ie. child, parent, cousins) when interacting with a singular node type. When the depth is provided the solution must communicate the corresponding node type’s information (node type attribute information, edge information). The relationship type input should act as a filter only retrieving node types that match the relationship type of the node type input.
- ability to filter node types on node type's metadata should be provided (example of metadata on node type: namespace, dependentOn)
- ability to retrieve a description for each node type & attribute to enable ease of user understanding
- ability to retrieve traversal paths
- return all traversal paths when provided a start and end node type
- indicate the shortest path available
- indicate the relative lengths of the other paths
- displayed on a UI sorted by shortest to longest path
- should also provide the ability to optionally provide multiple passthrough node types, defining the intermediate node types needing to be visited during the traversal.
- ability to provide information via a GUI
- interaction with node types (one at a time and multiple) to view their node type attributes, edge attributes, and other relative information
- example
- example
- ability to retrieve node types/edges and display the information based on the various filters aforementioned (depth, relationship type, metproperties, etc)[See example above]
- traversal paths are able to be queried
- example
- example
- interaction with node types (one at a time and multiple) to view their node type attributes, edge attributes, and other relative information
- ability to interact with an end user using a natural language processor
- responds to questions about the schema and edge rules in a conversational format
- extent of the available conversations should cover the features available on the ui
- example
- example
- ability to retrieve information about
- a property, when given a property of a node type as input
- a metaproperty, when given a metaproperty of a node type's property as input
- edges given the node type and edge property values
- edges given an edge type (ie tree, cousin, etc) for a node-type
- metadata, given a metadata field of a node type as input (ie DESCRIPTION, DEPENDENT_ON, CONTAINER, NAMESPACE, etc)
- ability to filter properties of a node type on metaproperties should be provided (example of metaproperties : required, indexed, searchable)
The solution must only depend on schema/edge rules files, it should not load graph data. The solution will not answer questions on the graph data.
As far as implementation details for the POC we initially thought this (when there was no schema service)
The GraphGraph Core can be absorbed as functionality provided in the schema service (unless folks have a strong use case against it)