AAI Edge Rule Enumerator Values

Owned by Keong Lim
Last updated: Aug 08, 2018
3 min read

References

Example from documentation

UML diagram for example edge rule
UML diagram for example edge rule

Example

Equivalent Example

Example

Equivalent Example

Example Edge Rule
{ “from”: “tenant”, “to”: “vserver”, “label”: “owns”, “direction”: “OUT”, “multiplicity”: “One2Many”, “contains-other-v”: “${direction}”, “delete-other-v”: “NONE”, “SVC-INFRA”: “!${direction}”, “prevent-delete”: “${direction}” }
Equivalent Edge Rule
{ “from”: “vserver”, “to”: “tenant”, “label”: “owns”, “direction”: “IN”, “multiplicity”: “One2Many”, “contains-other-v”: “!${direction}”, “delete-other-v”: “NONE”, “SVC-INFRA”: “${direction}”, “prevent-delete”: “!${direction}” }
How to read in/out/direction
How to read "from"/"to" and "direction" in this case: - the "in" node is "vserver" - the "out" node is "tenant"
How to read the label
How to read multiplicity
How to read contains-other-v
How to read delete-other-v
How to read SVC-INFRA
How to read prevent-delete



General Applicability

  • EdgeRules only apply to "relationship-list" relations in the schema, since the referenced object could be anything

  • EdgeRules do not apply to sub-component relations in the schema, since this is implicit and hard-coded behaviour



Field

Values

Notes

Field

Values

Notes

from

(literal string as entered in EdgeRule file)



Expected to match the "name" value of "xml-root-element" in OXM file.

Note that the "from|to" pair is normalised in the code according to alphabetical order, so that "cousin pairs" with the "to|from" ordering in the EdgeRule are also grouped together, e.g.

  • from "l-interface" to "logical-link" → "l-interface|logical-link"

  • from "logical-link" to "l-interface" → "l-interface|logical-link"

Also note that the hyphens "-" are removed from the names before comparison, so the following would be equivalent:

  • l-interface

  • linter-face

to

(literal string as entered in EdgeRule file)



Expected to match the "name" value of "xml-root-element" in OXM file.

Note that the "from|to" pair is normalised in the code according to alphabetical order, so that "cousin pairs" with the "to|from" ordering in the EdgeRule are also grouped together, e.g.

  • from "l-interface" to "logical-link" → "l-interface|logical-link"

  • from "logical-link" to "l-interface" → "l-interface|logical-link"

Also note that the hyphens "-" are removed from the names before comparison, so the following would be equivalent:

  • l-interface

  • linter-face

label

(literal string as entered in EdgeRule file)



By convention, appears to be one of:

  • isA

  • org.onap.relationships.inventory.AppliesTo

  • org.onap.relationships.inventory.BelongsTo

  • org.onap.relationships.inventory.BridgedTo

  • org.onap.relationships.inventory.ComposedOf

  • org.onap.relationships.inventory.DependsOn

  • org.onap.relationships.inventory.Destination

  • org.onap.relationships.inventory.ForwardsTo

  • org.onap.relationships.inventory.IsA

  • org.onap.relationships.inventory.LocatedIn

  • org.onap.relationships.inventory.MemberOf

  • org.onap.relationships.inventory.network.MemberOf

  • org.onap.relationships.inventory.PartOf

  • org.onap.relationships.inventory.Source

  • org.onap.relationships.inventory.Targets

  • org.onap.relationships.inventory.Uses

  • startsWith

  • tosca.relationships.AttachesTo

  • tosca.relationships.HostedOn

  • tosca.relationships.network.BindsTo

  • tosca.relationships.network.LinksTo

direction

  • IN

  • OUT

  • NONE (default value used when Tinkerpop Direction is null)

  • BOTH (default value used when string is unrecognised)

Based on and extended from https://tinkerpop.apache.org/javadocs/3.3.2/core/org/apache/tinkerpop/gremlin/structure/Direction.html

Comparison is case-sensitive

multiplicity

  • Many2Many

  • One2Many

  • One2One

  • Many2One (default value used when string is unrecognised)

Comparison ignores case

contains-other-v

  • IN

  • OUT

  • BOTH

  • NONE

  • ${direction}

  • !${direction}

This is an "edge property" that applies for traversal to the other vertex.

Comparison is case-sensitive

Note that "opposite" means:

  • IN → OUT

  • OUT → IN

  • BOTH → BOTH

  • NONE → BOTH



delete-other-v

  • IN

  • OUT

  • BOTH

  • NONE

  • ${direction}

  • !${direction}

This is an "edge property" that applies for traversal to the other vertex.

Comparison is case-sensitive

Note that "opposite" means:

  • IN → OUT

  • OUT → IN

  • BOTH → BOTH

  • NONE → BOTH

SVC-INFRA

  • IN

  • OUT

  • BOTH

  • NONE

  • ${direction}

  • !${direction}

This is an "edge property" that applies for traversal to the other vertex.

Comparison is case-sensitive

Note that "opposite" means:

  • IN → OUT

  • OUT → IN

  • BOTH → BOTH

  • NONE → BOTH

prevent-delete

  • IN

  • OUT

  • BOTH

  • NONE

  • ${direction}

  • !${direction}

This is an "edge property" that applies for traversal to the other vertex.

Comparison is case-sensitive

Note that "opposite" means:

  • IN → OUT

  • OUT → IN

  • BOTH → BOTH

  • NONE → BOTH

default

  • true

  • false (default value used when string is unrecognised)



Default EdgeRule will apply when no other more specific rule applies ?

Based on https://docs.oracle.com/javase/7/docs/api/java/lang/Boolean.html#valueOf(java.lang.String)

Comparison ignores case

description

(literal string as entered in EdgeRule file)



Optional for backwards compatibility with v12 and earlier (default value is empty string)

The EdgeRule JSON format does not permit comments (presence of comments appears to make the parser skip entries in the file).

Questions

  1. Is there a way to find/remove the unused/redundant EdgeRules from the json file?

  2. Is there any plan to simplify EdgeRules into an unambiguous canonical form (might be easier to read and write correctly)?

  3. How does the "default" property actually work? In v13, there are 226 EdgeRules with 224 having default "true" and 2 having default "false".