The invention empowers a non-technical business user to easily establish a central master of product relationship rules. It provides flexibility in the specification of relationship functionality and in the rules for membership in a collection. It implements a higher-order specification (“any” source relates to “same” target) and stores the data efficiently with automatic updates when data is created or retired. Key aspects to protect include: 1. Relationship types are richly specified. 2. Calculating members of collections a) Attribute-based rules for collection membership b) Dynamic joins for optimal performance c) Universal policy for all collections d) Storage efficiency) 3. “Any-Same” Higher-Order Abstraction
|
Document Author (alias) |
Jerre McQuinn |
|
Defensive Publication Title |
Mapping algorithm with rich relationship expression and higher-order abstraction |
|
|
|||||
|
|
Summary of the Defensive Publication/Abstract |
|
The invention empowers a non-technical business user to easily establish a central master of product relationship rules. It provides flexibility in the specification of relationship functionality and in the rules for membership in a collection. It implements a higher-order specification (“any” source relates to “same” target) and stores the data efficiently with automatic updates when data is created or retired. Key aspects to protect include: 1. Relationship types are richly specified. 2. Calculating members of collections a) Attribute-based rules for collection membership b) Dynamic joins for optimal performance c) Universal policy for all collections d) Storage efficiency) 3. “Any-Same” Higher-Order Abstraction
|
|
Description: |
||
|
Business utility: The diagram below depicts that many different relationship types ( renews, steps up, fulfills with) can be specified between any given collection, and in the lower left hand list of part numbers it illustrates that a collection can include (by rule specification) multiple part numbers. Relationship types can be self-referential (Office Standard SA renews with Office Standard SA). 1. Rich Relationship Type Specification: The diagram below shows how a user defines a relationship type with metadata that indicates the name, description, and whether the relationship type is forward (from left to right) or inverse (from right to left). A relationship type can be specified to be bi-directional, typically used for specifying equivalencies. The user specifies whether the collections are calculated and saved with many members or having only a single (individual to individual) member. Metadata about the relationship type is published in the result set. 2a. Rules-based Collection Membership:
|