Skip to content

Commit 5334a16

Browse files
committed
Updated pages
1 parent 94b32d1 commit 5334a16

File tree

2 files changed

+14
-9
lines changed

2 files changed

+14
-9
lines changed

src/app/docs/cookbook-taxonomy-inheritance/page.md

Lines changed: 10 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -18,7 +18,8 @@ We believe that human agency can be improved by offering generic, highly perform
1818

1919
All images are generated via the dfrnt.com data product builder.
2020

21-
{% figure src="https://miro.medium.com/v2/resize:fit:1400/format:webp/1*V1qW8MHyao1Gk2UmSqoYrw.png" alt="Visualisation showing how SKUs are connected through a product taxonomy. This is a narrow set, supporting the example where some record properties get inherited through the classes of the taxonomy." caption="Visualisation showing how SKUs are connected through a product taxonomy. This is a narrow set, supporting the example where some record properties get inherited through the classes of the taxonomy.)" %}{% /figure %}
21+
{% figure src="https://miro.medium.com/v2/resize:fit:1400/format:webp/1*V1qW8MHyao1Gk2UmSqoYrw.png" alt="Visualisation showing how SKUs are connected through a product taxonomy. This is a narrow set, supporting the example where some record properties get inherited through the classes of the taxonomy." caption="Visualisation showing how SKUs are connected through a product taxonomy. This is a narrow set, supporting the example where some record properties get inherited through the classes of the taxonomy." %}
22+
{% Learn how to get TerminusDB set up in your project in under thirty minutes %}
2223

2324
It is crucial to have generic problem-solving capabilities at hand. We believe digital exoskeletons is an apt term for what we provide, let us know in the comments below what you think of as more approachable terms!
2425

@@ -57,7 +58,8 @@ In essence, what is needed is the ability to build a data structure where you ha
5758

5859
The Legal Entity record would then have connected sub-objects for the legal entity’s Supplier Record and Customer Record respectively (and more), that are part of the Legal Entity record. Ideally, they are connected to the lifecycle with the Legal Entity top-level record in the system-of-record. When the Legal Entity record is deleted, the more specific records of it will be deleted as well. Setting up such restrictions is important to support.
5960

60-
{% figure src="https://miro.medium.com/v2/resize:fit:1400/format:webp/1*5xUSuv-6mfgvdI17I9HqWQ.png" alt="Information on a Legal Entity Record could be mirrored into Supplier or Customer representations when defined as part of the Legal Entity document. And they should include relevant properties of LegalEntity." caption="Information on a Legal Entity Record could be mirrored into Supplier or Customer representations when defined as part of the Legal Entity document. And they should include relevant properties of LegalEntity." %}{% /figure %}
61+
{% figure src="https://miro.medium.com/v2/resize:fit:1400/format:webp/1*5xUSuv-6mfgvdI17I9HqWQ.png" alt="Information on a Legal Entity Record could be mirrored into Supplier or Customer representations when defined as part of the Legal Entity document. And they should include relevant properties of LegalEntity." caption="Information on a Legal Entity Record could be mirrored into Supplier or Customer representations when defined as part of the Legal Entity document. And they should include relevant properties of LegalEntity." %}
62+
{% Learn how to get TerminusDB set up in your project in under thirty minutes %}
6163

6264
Below is what a very simplified JSON-LD record of what a Legal Entity could look like. Note the customerEntity and supplierEntity subdocuments in the JSON-LD document that must share their lifecycle with the master record. This would be controlled through for example cascading deletes in a traditional database.
6365

@@ -106,11 +108,13 @@ Consider a product taxonomy, here is a generic one with 6 levels that is sane en
106108

107109
Each Stock Keeping Unit would be fantastic to define in the same way, inheriting properties from the taxonomy but also keeping consistency across all SKU. For this example, we keep the Taxonomy Elements and Stock Keeping Units separate, but link them together.
108110

109-
{% figure src="https://miro.medium.com/v2/resize:fit:1400/format:webp/1*n976E91YPP3bT8IqejPijQ.png" alt="This is what the taxonomy looks like, with the SKUs for the examples on the left, all the way to the top level categories on the right" caption="This is what the taxonomy looks like, with the SKUs for the examples on the left, all the way to the top level categories on the right" %}{% /figure %}
111+
{% figure src="https://miro.medium.com/v2/resize:fit:1400/format:webp/1*n976E91YPP3bT8IqejPijQ.png" alt="This is what the taxonomy looks like, with the SKUs for the examples on the left, all the way to the top level categories on the right" caption="This is what the taxonomy looks like, with the SKUs for the examples on the left, all the way to the top level categories on the right" %}
112+
{% Learn how to get TerminusDB set up in your project in under thirty minutes %}
110113

111114
A common mistake to make is to not think through the relationship properly, each Taxonomy Element has an is-part-of relationship with the parent, and is not an is-a relationship tied to the type classifications (super-classing, sub-classing). This is why keep each type in a flat list as per below.
112115

113-
{% figure src="https://miro.medium.com/v2/resize:fit:1400/format:webp/1*Tqm3qld4cY2QI_gyKCuMSw.png" alt="The SKU has an isPartOf relationship to 5-ProductVariant, to 4, 3, 2, 1. SKU could arguably also be placed in the product taxonomy, here it was a preference to make the product taxonomy more manageable." caption="The SKU has an isPartOf relationship to 5-ProductVariant, to 4, 3, 2, 1. SKU could arguably also be placed in the product taxonomy, here it was a preference to make the product taxonomy more manageable." %}{% /figure %}
116+
{% figure src="https://miro.medium.com/v2/resize:fit:1400/format:webp/1*Tqm3qld4cY2QI_gyKCuMSw.png" alt="The SKU has an isPartOf relationship to 5-ProductVariant, to 4, 3, 2, 1. SKU could arguably also be placed in the product taxonomy, here it was a preference to make the product taxonomy more manageable." caption="The SKU has an isPartOf relationship to 5-ProductVariant, to 4, 3, 2, 1. SKU could arguably also be placed in the product taxonomy, here it was a preference to make the product taxonomy more manageable." %}
117+
{% Learn how to get TerminusDB set up in your project in under thirty minutes %}
114118

115119
All sub-classed types of the TaxonomyElements will include all properties from TaxonomyElement, including the faceting properties we want to support.
116120

@@ -140,7 +144,8 @@ optionally, if defined, get steward either from this record, or from parent reco
140144

141145
By allowing the business logic to be expressed simply and the information, as above, it is easy to understand, and it becomes easier to make a more formal representation. Again, here is the simple model, which can also be exported as JSON Schema for use outside of the system.
142146

143-
{% figure src="https://miro.medium.com/v2/resize:fit:1400/format:webp/1*CVaKpw8vjWcLV38l1Qg8fw.png" alt="A UML diagram indicating composition of CustomerEntry and SupplierEntry to LegalEntity" caption="A UML diagram indicating composition of CustomerEntry and SupplierEntry to LegalEntity" %}{% /figure %}
147+
{% figure src="https://miro.medium.com/v2/resize:fit:1400/format:webp/1*CVaKpw8vjWcLV38l1Qg8fw.png" alt="A UML diagram indicating composition of CustomerEntry and SupplierEntry to LegalEntity" caption="A UML diagram indicating composition of CustomerEntry and SupplierEntry to LegalEntity" %}
148+
{% Learn how to get TerminusDB set up in your project in under thirty minutes %}
144149

145150
The duns, name and steward are mandatory on the LegalEntity record information model, to ensure there is at least one value in the hierarchy, and optional in the sub-objects. Illustration is directly from the tool.
146151

src/app/page.md

Lines changed: 4 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -9,17 +9,17 @@ nextjs:
99

1010
---
1111

12-
Learn how to get TerminusDB set up in your project in under thirty minutes. {% .lead %}
12+
TerminusDB is the modern graph database for knowledge graphs and semantic content infrastructures. Learn how to get started with TerminusDB in under thirty minutes. {% .lead %}
1313

1414
{% quick-links %}
1515

1616
{% quick-link title="Installation" icon="installation" href="/docs/get-started/" description="Step-by-step guides to setting up your system and installing the library." /%}
1717

18-
{% quick-link title="Architecture guide" icon="presets" href="/docs/terminusdb-explanation/" description="Learn how the internals work and contribute." /%}
18+
{% quick-link title="Query unification" icon="presets" href="/docs/unification-of-variables-in-datalog/" description="Learn about the core differentiator of the query engine: query variable unification." /%}
1919

20-
{% quick-link title="Plugins" icon="plugins" href="/docs/documents-explanation/" description="Extend TerminusDB with third-party plugins or write your own." /%}
20+
{% quick-link title="TerminusDB Open Source" icon="plugins" href="/docs/terminusdb-explanation/" description="Learn more about the Apache 2.0 licensed TerminusDB database." /%}
2121

22-
{% quick-link title="API reference" icon="theming" href="/docs/openapi/" description="Learn to easily customize and modify your app's visual design to fit your brand." /%}
22+
{% quick-link title="Documents and Git-for-Data" icon="theming" href="/docs/documents-explanation/" description="Learn about the RDF Graph Documents API and Git-for-Data features." /%}
2323

2424
{% /quick-links %}
2525

0 commit comments

Comments
 (0)