@yottagraph-app/elemental-api-skill 1.0.0 → 1.1.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/package.json +1 -1
- package/skill/SKILL.md +38 -0
- package/skill/entities.md +35 -0
- package/skill/overview.md +27 -1
package/package.json
CHANGED
package/skill/SKILL.md
CHANGED
|
@@ -23,6 +23,44 @@ Use this skill when you need to:
|
|
|
23
23
|
2. **Get information**: Use the NEID to query sentiment, mentions, relationships, or events
|
|
24
24
|
3. **Dive deeper**: Retrieve full article details or explore connected entities
|
|
25
25
|
|
|
26
|
+
## Common Workflows
|
|
27
|
+
|
|
28
|
+
These examples show how to combine endpoints for multi-step data exploration.
|
|
29
|
+
Properties with value type `data_nindex` are entity IDs — resolve them with
|
|
30
|
+
another properties query to traverse the knowledge graph.
|
|
31
|
+
|
|
32
|
+
### Explore a new dataset (schema-first discovery)
|
|
33
|
+
|
|
34
|
+
New data sources are added regularly. Don't hardcode entity types or property
|
|
35
|
+
names. Instead, discover them at runtime:
|
|
36
|
+
|
|
37
|
+
1. Call `getSchema()` to list all entity types (flavors) and properties (PIDs)
|
|
38
|
+
2. Find entities of the type you're interested in using `findEntities()` with an `is_type` expression
|
|
39
|
+
3. Call `getPropertyValues()` to fetch data for those entities
|
|
40
|
+
|
|
41
|
+
See `schema.md` for the schema endpoints, `find.md` for the expression language.
|
|
42
|
+
|
|
43
|
+
### Get Edgar filings for a company
|
|
44
|
+
|
|
45
|
+
Edgar filings are linked to companies via properties. A company entity has a
|
|
46
|
+
`filings` property whose values are entity IDs for individual filing documents.
|
|
47
|
+
|
|
48
|
+
1. Search for the company: `POST /entities/search` with the company name → get NEID
|
|
49
|
+
2. Get the company's filing entities: `POST /elemental/entities/properties` with the NEID and the `filings` property → returns entity IDs for each filing
|
|
50
|
+
3. For each filing entity, get its details: `POST /elemental/entities/properties` with the filing entity IDs and properties like `filing_date`, `form_type`
|
|
51
|
+
4. Display the results
|
|
52
|
+
|
|
53
|
+
This pattern — entity → property (returns entity IDs) → query those entities —
|
|
54
|
+
works for any `data_nindex` property, not just filings. See `entities.md` for
|
|
55
|
+
details on property chaining.
|
|
56
|
+
|
|
57
|
+
### Find connected entities via relationships
|
|
58
|
+
|
|
59
|
+
1. Search for the starting entity → get NEID
|
|
60
|
+
2. Use `findEntities()` with a `linked` expression to find entities connected to it (see `find.md`)
|
|
61
|
+
3. Or use `getLinkedEntities()` for direct relationship traversal (see `relationships.md`)
|
|
62
|
+
4. Get properties for the connected entities
|
|
63
|
+
|
|
26
64
|
## Files in This Skill
|
|
27
65
|
|
|
28
66
|
See [overview.md](overview.md) for descriptions of each endpoint category:
|
package/skill/entities.md
CHANGED
|
@@ -123,6 +123,41 @@ Each Match contains:
|
|
|
123
123
|
}
|
|
124
124
|
```
|
|
125
125
|
|
|
126
|
+
## Property Chaining (`data_nindex`)
|
|
127
|
+
|
|
128
|
+
Some properties have value type `data_nindex`, meaning their values are entity
|
|
129
|
+
IDs rather than simple strings or numbers. This lets you traverse the knowledge
|
|
130
|
+
graph through properties:
|
|
131
|
+
|
|
132
|
+
1. Query an entity's properties → get values that are entity IDs
|
|
133
|
+
2. Query those entity IDs for *their* properties → get the next level of data
|
|
134
|
+
|
|
135
|
+
**Example: Edgar filings**
|
|
136
|
+
|
|
137
|
+
A company entity has a `filings` property. Each value is the entity ID of a
|
|
138
|
+
filing document. Each filing document entity has its own properties like
|
|
139
|
+
`filing_date` and `form_type`.
|
|
140
|
+
|
|
141
|
+
```
|
|
142
|
+
Company (NEID: 00416400910670863867)
|
|
143
|
+
→ property "filings" (data_nindex)
|
|
144
|
+
→ Filing entity (NEID: 12345678901234567890)
|
|
145
|
+
→ property "filing_date" → "2026-01-15"
|
|
146
|
+
→ property "form_type" → "10-K"
|
|
147
|
+
→ Filing entity (NEID: 09876543210987654321)
|
|
148
|
+
→ property "filing_date" → "2025-07-20"
|
|
149
|
+
→ property "form_type" → "10-Q"
|
|
150
|
+
```
|
|
151
|
+
|
|
152
|
+
To resolve this chain, make two `POST /elemental/entities/properties` calls:
|
|
153
|
+
first with the company NEID and `filings` property, then with the returned
|
|
154
|
+
filing entity IDs and `filing_date` + `form_type` properties.
|
|
155
|
+
|
|
156
|
+
**How to identify `data_nindex` properties:** Use `GET /schema` (see
|
|
157
|
+
`schema.md`) and look for properties with `value_type: "data_nindex"`. The
|
|
158
|
+
schema also tells you which entity types (`domain_findexes`) have each property
|
|
159
|
+
and what entity types (`target_findexes`) the values point to.
|
|
160
|
+
|
|
126
161
|
## Schema and Property Lookup
|
|
127
162
|
|
|
128
163
|
For understanding entity types (flavors), properties, and the data model, see **schema.md**. You'll need the schema because many API responses return only FIDs and PIDs — use it to translate these to human-readable names.
|
package/skill/overview.md
CHANGED
|
@@ -39,13 +39,39 @@ Most endpoints accept `start` and `end` parameters for filtering by date.
|
|
|
39
39
|
| [server.md](server.md) | Check server status and capabilities, as well as schema info including flavors and properties. |
|
|
40
40
|
| [llm.md](llm.md) | (Not currently available) AI-assisted queries |
|
|
41
41
|
|
|
42
|
+
## Discovery-First Approach
|
|
43
|
+
|
|
44
|
+
The knowledge graph contains many entity types and properties, and new datasets
|
|
45
|
+
are added regularly (e.g. Edgar filings, shipping data, financial instruments).
|
|
46
|
+
Do not hardcode entity types or property names. Instead:
|
|
47
|
+
|
|
48
|
+
1. **Get the schema first** — `GET /schema` returns all entity types (flavors)
|
|
49
|
+
and properties. See `schema.md`.
|
|
50
|
+
2. **Search by type or property** — use the expression language in `find.md`
|
|
51
|
+
to search for entities matching criteria from the schema.
|
|
52
|
+
3. **Get property values** — `POST /elemental/entities/properties` fetches
|
|
53
|
+
data. Properties with type `data_nindex` are entity IDs — query them again
|
|
54
|
+
to traverse the graph. See `entities.md` for details.
|
|
55
|
+
|
|
56
|
+
This pattern lets you work with any dataset without prior knowledge of what's
|
|
57
|
+
in the graph.
|
|
58
|
+
|
|
42
59
|
## Common Workflows
|
|
43
60
|
|
|
44
61
|
### "What's the sentiment for Apple?"
|
|
45
62
|
1. `entities.md` → Look up "Apple" to get NEID
|
|
46
63
|
2. `sentiment.md` → Query sentiment with the NEID
|
|
47
64
|
|
|
48
|
-
|
|
49
65
|
### "How are Microsoft and OpenAI connected?"
|
|
50
66
|
1. `entities.md` → Look up both companies to get NEIDs
|
|
51
67
|
2. `relationships.md` → Query links between the two NEIDs
|
|
68
|
+
|
|
69
|
+
### "What Edgar filings does Apple have?"
|
|
70
|
+
1. `entities.md` → Search for "Apple" to get NEID
|
|
71
|
+
2. `entities.md` → Get property values with the `filings` property (returns entity IDs)
|
|
72
|
+
3. `entities.md` → Get `filing_date` and `form_type` for each filing entity
|
|
73
|
+
|
|
74
|
+
### "What types of data are available?"
|
|
75
|
+
1. `schema.md` → Get the full schema (flavors + properties)
|
|
76
|
+
2. `find.md` → Search for entities of a specific type
|
|
77
|
+
3. `entities.md` → Get properties for those entities
|