AI Skill Report Card
Engineering Knowledge Graphs
Knowledge Graph Engineer
Quick Start14 / 15
Given a domain (e.g., "music streaming platform"), produce a structured knowledge graph design:
Domain: Music Streaming (MusGo)
ONTOLOGY DESIGN
- Classes: Artist, Track, Album, Genre, Playlist, User, Label
- Properties: performedBy, belongsToAlbum, hasGenre, releasedBy, curatedBy
- Constraints: Track must have exactly 1 Album; Artist can have 0..* Tracks
GRAPH STRUCTURE
(Artist)-[PERFORMS]->(Track)-[PART_OF]->(Album)
(Album)-[RELEASED_BY]->(Label)
(Track)-[HAS_GENRE]->(Genre)
(User)-[LISTENS_TO]->(Track)
(Playlist)-[CONTAINS]->(Track)
ENTITY MAPPING
- Source: Spotify API → Artist.spotify_id
- Source: MusicBrainz → Artist.mbid
- Merge key: normalized(artist_name) + release_year
RELATIONSHIP MODEL
- PERFORMS: cardinality N:N, weight=contribution_role
- SIMILAR_TO: inferred via co-listen embeddings, decay over time
- INFLUENCED_BY: curated, directional, non-transitive
EXPANSION STRATEGY
- Phase 1: core entities (Artist, Track, Album)
- Phase 2: behavioral edges (LISTENS_TO, SKIPS, LIKES)
- Phase 3: federate with external KG (Wikidata, MusicBrainz) via owl:sameAs
Recommendation▾
Add an example showing a poor/anti-pattern output (e.g., flat tagging instead of proper ontology) to illustrate contrast, not just sparse-input handling
Workflow14 / 15
Progress:
- Step 1: Clarify domain scope and key use cases (search, recommendation, reasoning, discovery)
- Step 2: Identify core entity classes and their attributes
- Step 3: Define ontology — class hierarchy, properties, constraints, disjointness rules
- Step 4: Design graph structure — node/edge schema, direction, cardinality
- Step 5: Map entities from source systems — identify keys, resolve duplicates/aliases
- Step 6: Define relationship model — explicit (curated) vs inferred (computed) edges
- Step 7: Plan expansion strategy — phased rollout, external federation, versioning
- Step 8: Validate with competency questions ("Can this graph answer X?")
Recommendation▾
Include a competency-question validation example to show how Step 8 is actually applied in practice
Examples16 / 20
Example 1: Input: "Build a knowledge graph for an e-commerce recommendation engine."
Output:
ONTOLOGY DESIGN
- Classes: Product, Category, Brand, Customer, Order, Review
- Object Properties: belongsToCategory, manufacturedBy, purchasedBy, reviewedBy
- Data Properties: price, rating, stock_count
GRAPH STRUCTURE
(Customer)-[PURCHASED]->(Product)-[BELONGS_TO]->(Category)
(Product)-[MADE_BY]->(Brand)
(Customer)-[REVIEWED {rating, sentiment}]->(Product)
(Product)-[FREQUENTLY_BOUGHT_WITH]->(Product)
ENTITY MAPPING
- Source: catalog DB → Product.sku (primary key)
- Source: CRM → Customer.customer_id
- Dedup: match Product by (sku) OR (normalized_title + brand)
RELATIONSHIP MODEL
- PURCHASED: transactional, timestamped, weighted by quantity
- FREQUENTLY_BOUGHT_WITH: inferred via market-basket analysis, refreshed weekly
- SIMILAR_TO: inferred via embedding cosine similarity, threshold > 0.85
EXPANSION STRATEGY
- Phase 1: Product-Category-Brand backbone
- Phase 2: Customer behavior edges (viewed, purchased, reviewed)
- Phase 3: Federate with supplier KG for provenance and sustainability data
Example 2: Input: "gk"
Output:
ONTOLOGY DESIGN
- Input too sparse to derive domain. Requesting minimal placeholder scope: generic entity-relationship graph.
- Classes: Entity, Relation
- Properties: relatedTo (generic)
GRAPH STRUCTURE
(Entity)-[RELATED_TO]->(Entity)
ENTITY MAPPING
- Define primary key once domain is specified.
RELATIONSHIP MODEL
- Placeholder generic relation; refine once domain and use cases are known.
EXPANSION STRATEGY
- Await domain input (e.g., industry, entities, use cases) to build a meaningful ontology.
Recommendation▾
Consider adding a brief note on graph database technology choices (RDF/OWL vs property graph like Neo4j) since the model touches both paradigms without clarifying when each applies
Best Practices
- Start with competency questions — the graph exists to answer specific queries; design backward from those.
- Separate explicit/curated edges from inferred/computed edges; tag provenance and confidence on inferred ones.
- Use stable, namespaced IDs for entities (URIs or UUIDs); never rely on mutable display names as keys.
- Model cardinality and directionality explicitly — ambiguity here causes downstream query errors.
- Favor reusing standard vocabularies (schema.org, FOAF, OWL, SKOS) before inventing new ontology terms.
- Design for incremental expansion — ship a minimal core ontology first, then layer behavioral and federated data.
- When federating external KGs, always map equivalence explicitly (
owl:sameAs,skos:exactMatch) rather than merging silently.
Common Pitfalls
- Don't conflate a class hierarchy with a tagging system — "Genre" as a class needs different treatment than free-text tags.
- Don't hardcode N:N relationships as 1:N to simplify early modeling; it forces painful migrations later.
- Don't skip entity resolution/dedup strategy — duplicate entities silently corrupt graph analytics.
- Don't mix inferred and asserted facts in the same edge type without a provenance/confidence attribute.
- Don't over-engineer the ontology upfront — avoid deep class hierarchies before real query patterns are known.
- Don't ignore versioning — ontologies evolve; changes to class/property definitions need migration plans.