The Resume Graph Explorer.

OPTIONAL for both email and jobTitle: if the file were missing those triples, the person would still appear with those columns unbound. The query structure tells you the data is optional even when it is present — a modeling signal that these facts may not exist for every person in a larger dataset.

Notice: foaf:mbox takes a mailto: URI, not a plain string. The bound value is the full IRI, not just the address string. To get the address as a string you would use STR(?email) or REPLACE(STR(?email), "mailto:", "").

1. Add foaf:givenName and foaf:familyName to the OPTIONAL block. Do they appear? Check resume-001.ttl to verify they are asserted.

2. Remove both OPTIONAL blocks and make email and jobTitle required triple patterns. What changes? Does the person still appear?

3. The resume document node (https://sensemaking-ai.com/resume/alex-rivera/001) is also in the graph. Add a second pattern to the WHERE clause that retrieves the document's dcterms:title. What does the result look like when you join person facts and document facts in the same query?

The current job (Northwind) has no sensemaking:endDate triple — it is ongoing. OPTIONAL keeps that row in the result with ?end unbound. Without OPTIONAL, the current job disappears from the result entirely. This is a common data modeling convention: no end date means the role is current.

Notice the two-hop traversal: person → Employment event → Organization. Each hop is a triple pattern. The Employment event node earns its existence by carrying the role and dates — properties that cannot live on an edge in RDF.

1. Add education to the results using UNION: UNION { ?person sensemaking:hasEducation ?edu . ?edu sensemaking:institution ?org . ?edu sensemaking:degree ?role . ?edu sensemaking:startDate ?start . ?org schema:name ?orgName . OPTIONAL { ?edu sensemaking:endDate ?end . } }. Do all three records (two jobs, one degree) appear?

2. Add schema:description to the SELECT via OPTIONAL. Does the description appear for both jobs? What LANG filter behavior do you expect if descriptions had language tags?

3. Filter to only jobs that have ended: FILTER (BOUND(?end)). Who appears? What does BOUND() check?

The path skos:exactMatch/skos:broader chains two predicates: from the local skill concept to the ESCO stub via exactMatch, then from the ESCO stub to its broader category. This is the interop query from the 1.1 synthesis document, now running on real data.

In a production graph with the full ESCO dataset loaded, the same query reaches the actual European occupational taxonomy — ~14,000 skill concepts organized into a hierarchy. The query pattern does not change; only the data behind skos:exactMatch changes (local stubs vs. live ESCO IRIs).

1. Extend the path to two hops of broader: skos:exactMatch/skos:broader/skos:broader. What do the domain labels become? (They should reach ICT skills — the top-level ESCO category in the stubs.)

2. Change to skos:exactMatch/skos:broader+ (one-or-more hops of broader). How many rows appear now? For each skill, what is the chain of broader categories returned?

3. Remove the LANG filters. How does the row count change? Open resume-001.ttl and check the language tags on skos:prefLabel values — all are tagged @en, so the filter should not change results here. When would it matter?

foaf:primaryTopic connects the document to the person it is about. This query demonstrates that document and person are separate nodes: the document's dcterms:created date is when the document was created, not when Alex was born or when he started working. Keeping these distinct is why the document/person split exists.

This distinction becomes critical in Module 3 (provenance and reification): to say "this claim about Alex comes from resume version 001, created 2024-11-01," you need the document as a separate, citable node.

1. Change the query to DESCRIBE the document node (DESCRIBE ?doc WHERE { ?doc a sensemaking:Resume . }). Compare the DESCRIBE output to the SELECT output — what extra triples appear?

2. Add a second triple pattern: ?doc dcterms:subject ?subject as an OPTIONAL. Does ?subject bind? Check resume-001.ttl — is dcterms:subject asserted on the document?

3. What would you put in dcterms:creator for this document — the IRI for Alex Rivera (the person the resume is about) or an IRI for the person who submitted the resume? Are they always the same? What does this tell you about the vocabulary design decision?

Notice that the local skill label and the ESCO label are different — deliberately. The resume uses a shorter, colloquial label ("Python") while ESCO uses a more precise, action-verb label ("use a scripting language: Python"). Both are correct; they serve different audiences. The skos:exactMatch link asserts they refer to the same concept without forcing either label to change.

Machine learning is "intermediate" and does not appear. Change the FILTER to ?level = "intermediate" to confirm.

1. Remove the FILTER on level. All three skills appear. Change the SELECT to include ?level and sort by DESC(?level) — what ordering does string sort give "advanced" vs "intermediate"? Is alphabetical sort on skill level meaningful?

2. Add skos:altLabel to the SELECT for both the local skill and the ESCO concept. What do you expect? Check resume-001.ttl — which concepts have skos:altLabel triples?

3. Change the query to use ASK: is there at least one skill at "advanced" level with an ESCO link? What does a true result tell you, and what can it not tell you under the open-world assumption?