updated doc

SmartDataAnalytics · Aug 22, 2024 · b2c03f2 · b2c03f2
1 parent e533681
commit b2c03f2
Show file tree

Hide file tree

Showing 3 changed files with 15 additions and 11 deletions.
diff --git a/docs/graphql/reference/index-directive.md b/docs/graphql/reference/index-directive.md
@@ -28,7 +28,7 @@ The `@index` directive converts a field’s output into a JSON object, where:
 
 #### Example
 
-Consider the following GraphQL schema:
+Consider the following GraphQL query:
 
 ```graphql
 {

diff --git a/docs/graphql/reference/one-and-many.md b/docs/graphql/reference/one-and-many.md
@@ -37,10 +37,12 @@ These directives can be applied to fields to control their cardinality and the c
 Consider the following example:
 
 ```graphql
-type Parent @one(self: false, cascade: true) { 
-  # The Parent field is still effectively @many, but the cardinality cascades to its children
-  Child1 # Child1 inherits @one cardinality from Parent
-  Child2 # Child2 also inherits @one cardinality from Parent
+{
+  parent @one(self: false, cascade: true) { 
+    # The Parent field is still effectively @many, but the cardinality cascades to its children
+    child1 # child1 inherits @one cardinality from Parent
+    child2 # child2 also inherits @one cardinality from Parent
+  }
 }
 ```
 
@@ -50,7 +52,7 @@ type Parent @one(self: false, cascade: true) {
    - `self: false`: The `@one` directive does **not** apply to the `Parent` field itself. The field remains multi-valued (`@many`).
    - `cascade: true`: The `@one` behavior cascades to the child fields (`Child1` and `Child2`), making them single-valued.
 
-2. **Child Fields**: Both `Child1` and `Child2` automatically inherit the `@one` cardinality from the `Parent` due to the cascading effect. They are treated as single-valued fields.
+2. **Child Fields**: Both `child1` and `child2` automatically inherit the `@one` cardinality from the `Parent` due to the cascading effect. They are treated as single-valued fields.
 
 #### Understanding Cardinality Control
 

diff --git a/docs/graphql/reference/pattern.md b/docs/graphql/reference/pattern.md
@@ -29,22 +29,24 @@ The `@pattern` directive supports the following arguments:
 
 #### Example
 
-Here is an example demonstrating how to define a `MusicalArtist` type using the `@pattern` directive:
+Here is an example demonstrating how to define a `MusicalArtists` field using the `@pattern` directive:
 
 ```graphql
-type MusicalArtist @pattern(of: "?s a dbo:MusicalArtist", from: "s", to: "s") {
-  label @pattern(of: "?s rdfs:label ?o", from: "s", to: "o")
+{
+  MusicalArtists @pattern(of: "?s a dbo:MusicalArtist", from: "s", to: "s") {
+    label @pattern(of: "?s rdfs:label ?o", from: "s", to: "o")
+  }
 }
 ```
 
 #### Explanation
 
-1. **MusicalArtist Field**: The `MusicalArtist` type is associated with the graph pattern `?s a dbo:MusicalArtist`, where the `s` variable acts as both the source and target.
+1. **MusicalArtists Field**: The `MusicalArtists` type is associated with the graph pattern `?s a dbo:MusicalArtist`, where the `s` variable acts as both the source and target.
 2. **Label Field**: The `label` field is defined with a nested pattern `?s rdfs:label ?o`, where `s` is the source and `o` is the target.
 
 #### Rule for Implicit Joins
 
-By default, a field’s source variables (defined by `from`) are automatically joined with its parent’s target variables (defined by `to`). This allows seamless chaining of patterns without redundant variable specification.
+By default, a field’s source variables (defined by `from`) are automatically joined with its parent’s target variables (defined by `to`). This allows seamless chaining of patterns without redundant variable specification. The precise join type is a [LATERAL join](https://github.com/w3c/sparql-dev/issues/100).
 
 #### Notes