Coverage is scoped to Modules 1 and 2 — foundations and modeling. Module 3 and 4 vocabulary (reification approaches, SHACL constructs, GraphRAG, federation) gets added when those modules come online. The glossary grows with the curriculum rather than predicting what hasn't been written yet.
Entries marked contested have multiple legitimate definitions in working use. Where that happens, the curriculum's position is named, not hidden. For terms with a single uncontroversial definition, a quick Wikipedia paraphrase wouldn't earn its place here — those entries cross-link out instead of duplicating.
Use ASK when the question is yes/no — does at least one match exist? — and the actual matches don't matter. Cheaper than SELECT because the engine can stop at the first hit. Useful in validation flows where you want a boolean answer about whether some pattern holds.
The conjunction of triple patterns inside a WHERE clause, without OPTIONAL, UNION, or FILTER. A SPARQL engine matches a BGP by finding every assignment of variables that satisfies all the patterns simultaneously. Most SPARQL queries are at heart a BGP plus modifiers; understanding BGPs first makes the rest of SPARQL easier to read.
Useful when you need to group properties but don't care to reference the grouped thing from outside. In Turtle, written as [ ... ] for anonymous use or with an underscore-colon prefix (_:b1) for named local reference. The trap: blank nodes are scoped to their file or graph. Two blank nodes from different sources can't be reliably matched even if every property aligns. If a thing will be referenced from elsewhere, give it a real URI instead.
An OWL restriction can constrain a property to exactly N values, at least N, at most N, or some combination. Minimum-one cardinality is the most common in practice ("a Ninja must have at least one village"). The temptation to add cardinality constraints early is strong; resist it until you have real data to validate against. Premature cardinality is a common source of "the reasoner won't accept my data" pain.
In cognitive science, categories are how minds carve experience into manageable kinds, with fuzzy boundaries and prototype effects (Rosch's classic work). In ontology engineering, the categorical work gets formalized as classes with crisp membership conditions. The translation is lossy in both directions: real categories are messier than OWL classes, and an OWL class never quite captures the family resemblance that makes a category cognitively useful. Naming the gap matters when discussing modeling decisions with domain experts.
An RDFS or OWL class is a URI-identified set whose members are connected via rdf:type. Classes can be subclassed (rdfs:subClassOf), declared equivalent (owl:equivalentClass), or marked disjoint (owl:disjointWith). The shift in mental model from object-oriented programming is real: an OWL class is defined by what's true of its members, not by what methods it offers. Inheritance in OWL means set inclusion, not behavior reuse.
The classic database mindset: if the customers table has no entry for Alice, Alice is not a customer. RDF and OWL reject this by default — see open-world assumption. CWA returns in SHACL, which lets you say "for this validation, treat the data as complete" without abandoning the open-world model for inference. Knowing when each regime is right is the central judgment call in any real deployment.
open-world assumptionmonotonic reasoningunique name assumption
Philosophers and psychologists argue about what concepts are — definitions, prototypes, exemplars, theories. Knowledge engineering largely sidesteps the debate by working with classes (formal, set-theoretic, with crisp membership) instead. The translation from "concept" to "class" loses prototypicality and fuzzy edges; sometimes that loss is acceptable, sometimes it forces SKOS or a fuzzier modeling approach. Naming what's lost helps justify modeling decisions to non-technical stakeholders.
A SKOS concept scheme groups skos:Concept instances under a single namespace with relations like skos:broader and skos:narrower. Use this when the structure is taxonomic but not strictly class-based — concepts don't need disjointness, can be polyhierarchical, and don't require the rigor of OWL. ESCO (occupations), MeSH (medical subjects), and the Getty AAT (art and architecture) are all concept schemes.
Where SELECT returns variable bindings, CONSTRUCT returns a new graph built from a template using those bindings. The workhorse of inference materialization: write the rule as a SPARQL pattern, emit the inferred triples, store them. CONSTRUCT is also the cleanest way to transform one vocabulary into another — read the source pattern, emit the target shape.
The simplest form is a flat list of allowed values for a field. The richest forms (concept schemes, taxonomies, ontologies) add hierarchy, equivalences, and definitions. Most enterprise data quality work, when done well, starts here — agree on the terms before arguing about the schema. The semantic web's tooling gives controlled vocabularies global identifiers and machine-readable relations, but the underlying discipline predates RDF by centuries.
An RDF literal optionally carries an XSD datatype URI declaring how to interpret it. "42"^^xsd:integer is a number; "42"^^xsd:string is a string of two characters. Untyped literals default to xsd:string. Datatypes matter for filtering ("find all dates after 2020"), arithmetic, and validation; mixing typed and untyped literals in the same predicate is a frequent source of "why doesn't my query return anything" frustration.
The least specified of the four query forms — what counts as "everything" is up to the implementation. Useful for exploration ("what does Wikidata have on Q42?") and rarely useful for production queries because the result shape is non-portable across endpoints. Treat it as a debugging tool, not a building block.
owl:disjointWith tells the reasoner that membership in class A is incompatible with membership in class B. Useful for catching errors — if a Person is asserted to be a Place, the reasoner can complain. Underused in practice because most ontologies don't bother declaring disjointness, which means most reasoners can't catch the contradictions that disjointness would expose. Declare it when the boundary actually matters.
Declaring rdfs:domain :Ninja on :hasJutsu says that anything appearing as the subject of :hasJutsu is a Ninja. Note the direction of the rule: domain is an inference, not a validation. If the data says :RockLee :hasJutsu :PrimaryLotus without RockLee being typed as a Ninja, RDFS will infer the type rather than reject the data. SHACL exists in part to flip this from inference to validation when application logic needs the latter.
One of the oldest standardized RDF vocabularies, originally for library and archival metadata. The DCMI Terms namespace (dcterms:) is what's used today; the older Dublin Core Elements (dc:) is mostly legacy. Reach for it whenever you're describing metadata about a resource rather than properties of the thing itself: who created it, when, what license, what source.
Wikidata's endpoint is https://query.wikidata.org/sparql. A locally-running Fuseki exposes one at http://localhost:3030/<dataset>/query. The term is overloaded — sometimes it means the URL, sometimes the triplestore behind it; context disambiguates. Federation depends on multiple endpoints reachable simultaneously, which is part of why federated queries are powerful in theory and fragile in practice.
owl:equivalentClass tells the reasoner that membership in class A implies membership in class B and vice versa. Distinct from subClassOf in both directions and from sameAs in that it operates on classes, not individuals. Useful for vocabulary alignment — declare :Person owl:equivalentClass foaf:Person and a reasoner can move freely between the two vocabularies. Use with care: equivalence cascades through all member-level reasoning.
SERVICE keyword
Powerful in theory: query your local graph and join with Wikidata in one call. Brittle in practice: network latency dominates, the remote endpoint can rate-limit or time out, and silent schema changes at the remote source break queries with no warning. Most production systems materialize external data locally and refresh on a schedule rather than relying on live federation. Module 4 surfaces this tradeoff explicitly.
Applies a boolean expression to existing variable bindings — range checks (?d > "2020-01-01"^^xsd:date), regex (REGEX(?name, "Uchiha", "i")), presence tests (FILTER EXISTS { ... }). FILTER cannot introduce new bindings; if no other pattern binds the variable, the filter operates on unbound and produces nothing. The "empty result" pitfall is often a FILTER on an unbound variable.
Predates schema.org by years. foaf:Person, foaf:knows, foaf:name, foaf:homepage. Still standard in some academic and linked-data communities, increasingly replaced by schema:Person in modern work. Reach for FOAF when working with older graphs or in social-network domains where it's the established choice; reach for schema.org when starting fresh.
Minsky's 1974 frames captured everyday knowledge as structured templates: a "restaurant" frame has slots for cuisine, location, server, bill. Frame-based knowledge representation languages (KL-ONE, Loom, OKBC) are direct ancestors of OWL — the OWL class with property restrictions is the same idea, with the cognitive flexibility (defaults, exceptions, prototypicality) stripped out for the sake of decidable reasoning. Naming the lineage helps when explaining ontology design to domain experts familiar with frames or schemas.
An RDF graph is a labeled directed graph whose edges are triples — every edge has a single URI label (the predicate). A property graph (Neo4j-style) is also a labeled directed graph but each edge can carry multiple key-value properties natively. The term "graph" is shared across both models and they're often conflated in writing. Module 1 leans into the contrast: the choice between RDF and property graphs is one of the most consequential modeling decisions for any knowledge-graph project.
Where a basic graph pattern is conjunction only, a graph pattern adds alternation, negation, and conditional matching. Most real-world SPARQL queries are graph patterns, not BGPs. The mental model is: describe the shape of the subgraph you want, then have the engine find every assignment of variables that fits the shape.
RDFS inference is simple: subclass and subproperty propagation, domain and range type assignment. OWL inference is powerful and computationally expensive: equivalence, restrictions, disjointness, cardinality. SHACL Advanced and SWRL extend further with custom rules. "Inference" is overloaded — it can mean the act of deriving (process) or the derived triple itself (result); context disambiguates.
rdf:type
"Instance" and "individual" are used interchangeably; OWL prefers "individual." The same URI can be an instance of multiple classes simultaneously — RDF and OWL don't enforce single inheritance. Whether something should be modeled as an instance or a class is one of the design judgment calls that compounds — see punning for the case where the answer is "both."
owl:inverseOf says that if :parent is the inverse of :child, then asserting :Alice :child :Bob lets the reasoner infer :Bob :parent :Alice. Useful and dangerous: every inverse declaration roughly doubles the inferred triple count the reasoner maintains. Declare inverses when both directions of the relationship are queried in practice; skip them when only one direction is.
Practically every modern RDF tool accepts IRIs. The terms URI and IRI are used interchangeably in casual writing; the W3C specs distinguish them for compliance reasons. Unless you're working with non-ASCII URIs explicitly, the distinction rarely surfaces.
The RDF format with the strongest adoption outside the semantic-web community, largely because schema.org markup on websites uses JSON-LD. The @context block maps JSON keys to URIs, turning a familiar JSON document into a valid RDF graph. Reach for JSON-LD when RDF needs to coexist with web APIs or JavaScript ingestion; reach for Turtle when humans need to read or write the data.
The term carries three loads in modern use: (1) the RDF/semantic-web flavor, with URIs, formal semantics, and W3C standards; (2) the labeled-property-graph flavor (Neo4j, TigerGraph, Memgraph), without formal semantics but with native edge properties; (3) the marketing flavor — anything graph-shaped that ships in an analytics product. The curriculum uses sense (1) as default but treats the distinction as a first-class topic. Module 1 makes the LPG-vs-RDF comparison explicit; Module 4 surfaces the LLM-era reality that the current renaissance is graph-shaped but not necessarily RDF-shaped, which is part of why a practitioner fluent in both traditions is unusually well-positioned.
Written as "hello"@en, "こんにちは"@ja. SPARQL can filter by language (FILTER(LANG(?label) = "en")) and Wikidata leans on language-tagged literals heavily — most labels are multilingual. Use language tags for human-readable text; reserve plain untyped strings for codes and identifiers. The IETF BCP 47 spec defines valid tags (en, en-GB, zh-Hant, etc.).
Codified by Berners-Lee in 2006 as four rules: use URIs as names, use HTTP URIs (so they dereference), return useful info when someone looks one up, include links to other URIs. The semantic web is the broader vision; linked data is the practical methodology. The Linked Open Data Cloud diagram is a visualization of how successful (and selective) this methodology has been in practice — life sciences, government, library science have invested heavily; most of the commercial web has not.
Literals carry either a language tag (for strings) or a datatype (for everything else); a plain string with neither defaults to xsd:string. Cannot appear as the subject of a triple in standard RDF, only as an object. RDF-star relaxes this for embedded triples but most tooling assumes the classic restriction. Mixing typed and untyped literals on the same predicate is a frequent source of "why doesn't my SPARQL filter match anything" debugging.
The classic tradeoff: materialize and queries are fast but results go stale on data update; reason at query time and results are fresh but queries are slow. Production systems usually materialize and accept staleness, with rebuild schedules tied to update frequency. SPARQL CONSTRUCT queries are the most common materialization tool. Knowing which lever to pull — and how often — is a senior judgment call.
RDFS and OWL reasoning are monotonic by design: more data can only add to what's inferred, never retract it. This is what makes RDF "honest" but also what makes it bad at exceptions ("birds fly, except penguins"). Non-monotonic reasoning exists in other formalisms (default logic, answer set programming); RDF deliberately doesn't. The trade is intentional — monotonicity is what makes large-scale reasoning tractable and federated reasoning sound.
One of four standard approaches to reification. Put related triples in a graph, attach metadata to the graph URI, and the metadata describes the contained triples without bloating each one individually. SPARQL's GRAPH keyword scopes patterns to specific named graphs; the dataset abstraction in SPARQL 1.1 is named-graph-aware throughout. Useful for source tracking, versioning, and access control. Module 3 treats named graphs as the recommended reification approach for the Naruto provenance project.
RDF triples are binary by definition: subject, predicate, object. A fact like "Itachi killed Shisui under orders, at age 13" has at least four roles (actor, victim, motive, time) and can't be a single triple. The standard pattern is to introduce an Event instance and attach properties for each role. The Ontology Design Patterns portal documents the n-ary relation pattern formally; one of the four reification approaches in Module 3.
Verbose by design. Meant for machines and version-control diffs, not for humans to read. Every URI is spelled out in full; every line is independently valid. Useful when you want to see exactly what a triple is, stripped of Turtle's prefix sugar and grouping syntax. Most triplestores can serialize to N-Triples on request.
Can be a URI, a blank node, or a literal. The only position in a triple where a literal is allowed in standard RDF. The choice between making an object a literal (a date as xsd:date) vs. a URI (a date as a resource with multiple representations) is a modeling decision worth pausing over — literals are simpler, URIs are extensible.
In knowledge engineering, an ontology is a file (or set of files) declaring classes, properties, restrictions, and instances, with the semantics of those declarations governed by a standard like OWL. Tom Gruber's working definition — "a formal, explicit specification of a shared conceptualization" — is the most cited. The engineering sense deliberately narrows the philosophical one: an OWL ontology says what categories exist in a chosen model, not what exists in the world. The curriculum uses "ontology" in this engineering sense unless explicitly qualified.
From Aristotle forward: what kinds of things are there, what makes them the kinds they are, what relationships hold between them. The knowledge-engineering use of "ontology" borrowed this term in the 1990s, and the borrowing was honestly somewhat presumptuous — an OWL file specifies a model, not a metaphysics. Worth knowing the genealogy when talking to philosophers, domain experts in humanities, or anyone who notices the appropriation. Naming the disciplinary tension can earn credibility in stakeholder conversations.
If the graph doesn't say Alice has children, that doesn't mean Alice is childless — only that this graph hasn't asserted it either way. Coming from SQL or property graphs, this feels broken at first. The shift from "this is broken" to "this is honest" is the inflection point of learning to think semantically. SHACL exists in part to layer closed-world validation on top when application logic needs it; the underlying inference model stays open. The OWA is what makes RDF appropriate for data integration across sources you don't control — no single source needs to be complete.
closed-world assumptionmonotonic reasoningunique name assumption
The left outer join of SPARQL. Use it for properties that might not be present, without dropping the parent resource from results. Stacks of OPTIONAL clauses are a code smell — three or more in a single query usually signals that the data model wants reshaping. The unbound variables OPTIONAL produces interact subtly with FILTER; check the spec when the behavior surprises you.
Sits on top of RDF: every OWL file is also valid RDF, but the converse isn't true. The name is a deliberate Winnie-the-Pooh reference (OWL, not WOL). Has five profiles trading expressive power for tractability — DL, EL, QL, RL, and Full — each with different reasoning guarantees. Most ontology design work uses OWL DL through Protégé; production deployments often use EL or RL for performance.
Without DL's constraints, anything can be both class and instance, every restriction is allowed, and any RDF graph that uses OWL terms is a valid OWL Full ontology. Useful conceptually, impractical for tooling — no reasoner is guaranteed to terminate. Most ontologies described as "OWL" are actually OWL DL.
Reasoning in QL can be implemented as SQL query rewriting — the ontology rewrites the query, and the database answers it. The foundation of ontology-based data access (OBDA) work. Less common in semantic-web tutorials than DL or EL but important wherever an ontology sits in front of a relational store.
The OWL semantics that map cleanly to a rule engine or graph-database materialization pass. The right profile when you want OWL inference on top of existing rule-engine or graph-database infrastructure, rather than installing a dedicated DL reasoner.
Always a URI; literals and blank nodes can't be predicates. Naming predicates well is one of the small modeling decisions that compounds across an ontology — :hasJutsu reads naturally; :jutsu would be ambiguous about direction; :hasJutsuRelation is bureaucratic. The convention is camelCase, lowercase first letter, verb-ish.
In OWL, properties are classified as object properties (link two resources), datatype properties (link a resource to a literal), or annotation properties (carry metadata without reasoning impact). Properties have domains, ranges, and characteristics (transitive, symmetric, inverse, functional). "Predicate" and "property" both refer to the same thing but signal different contexts — "predicate" leans toward describing triples; "property" leans toward describing ontology design.
?p foaf:knows+ :Naruto matches anyone connected to Naruto by one or more knows hops. Variants: * for zero or more, ? for zero or one, | for alternation, / for sequence, ^ for inverse direction. Property paths make traversal queries dramatically more readable than the same logic expressed as repeated joins, and they're one of the SPARQL 1.1 features Cypher users tend to appreciate quickly.
Core classes: prov:Entity (things), prov:Activity (what happened), prov:Agent (who did it). Core properties: prov:wasAttributedTo, prov:wasGeneratedBy, prov:wasDerivedFrom. The right choice when tracking provenance at the assertion level — Module 3's Naruto reification project layers PROV-O over named graphs for source attribution.
"Software Engineer" might be an instance of "Job Title" (a class of job-title concepts) and itself a class whose instances are individual software engineers. OWL 2 allows the same URI to be interpreted at the right type from context — class in one statement, instance in another. Useful when you genuinely need it, confusing when you don't. Most modeling decisions that seem to need punning are actually decisions that should be cleaner — usually splitting the URI into two related ones.
Written conceptually as (subject, predicate, object, graph). The TriG and N-Quads serializations write quads directly; Turtle writes triples and leaves graph membership implicit. Datasets in SPARQL 1.1 are effectively sets of quads, with a default graph (unnamed) and zero or more named graphs.
Like domain but on the other side. Declaring rdfs:range :Village on :memberOfVillage says that anything appearing as the object of that property is a Village. And again, this is an inference rule, not a validation rule — RDFS infers the type rather than rejecting bad data. SHACL is what flips this from "infer membership" to "validate membership" when application logic needs the latter.
Knowledge as triples of subject, predicate, object, where subjects and predicates are URIs and objects are URIs or literals. Everything else in the semantic-web stack — RDFS, OWL, SPARQL, SHACL, SKOS — is built on top of this primitive. The data model itself is almost embarrassingly simple; the power comes from what's layered on top, and from the discipline of using global URIs for everything that needs to be referenced from elsewhere.
The first standardized RDF serialization, and the one that gave RDF much of its early bad reputation. Hard to read, hard to write by hand. Turtle and JSON-LD have replaced it for new work. Worth knowing it exists because older ontologies and some tools still default to it — when Protégé saves to RDF/XML by default, switch to Turtle.
Sits between RDF (data model) and OWL (full ontology language). Provides rdfs:Class, rdfs:subClassOf, rdfs:domain, rdfs:range, rdfs:label, rdfs:comment. Most real ontologies use RDFS plus a useful subset of OWL — Allemang's "RDFS Plus" framing captures this practice well. The RDFS-only sweet spot is taxonomies with light type structure; once you need cardinality or equivalence, you've moved into OWL.
HermiT and Pellet are the classic OWL DL reasoners; ELK specializes in OWL EL; rdflib and Apache Jena include simpler RDFS reasoners. Choosing a reasoner is mostly a choice about which OWL profile you need and how much data you're reasoning over. The performance gap between EL and DL reasoners on large ontologies is large enough to drive profile selection.
Four standard approaches exist: classical RDF reification (using rdf:Statement with its quartet of properties), n-ary relations (turning the relation into a class), named graphs (putting the assertion in a labeled container), and RDF-star (annotating the triple directly with the <<>> syntax). Each trades verbosity, query ergonomics, and tool support differently. Module 3 makes the comparison explicit; reification verbosity is one of the most-cited reasons people prefer property graphs.
"Every Ninja has at least one Village" is a minimum-cardinality restriction on memberOfVillage for the Ninja class. Restrictions are how OWL classes get their "defined by what's true of their members" character. The temptation to stack restrictions early is strong; resist until the data demands them. Every premature restriction is a future bug, usually surfacing as "the reasoner won't accept my data."
owl:sameAsa declaration that two URIs refer to the same individual
The reasoner then treats every property of one URI as a property of the other — assertions about Alice become assertions about her aliased self. Powerful and dangerous: sameAs collapses all attributes. If :Dagny owl:sameAs :Barbara, properties meaningful to only one of the two personas merge inseparably. Use skos:exactMatch when the intent is "same referent, keep attribute sets separate" — this is one of the alignment-vocabulary decisions Module 3 surfaces in detail.
From Bartlett, Piaget, Rumelhart: schemas are how minds organize experience into reusable templates. The semantic web's "schema" inherits the name but only part of the meaning: an OWL or RDFS schema specifies formal class and property structure, with none of the flexibility, defaults, or fuzzy edges of a cognitive schema. Cog-sci framing earns its place when explaining ontology work to non-technical stakeholders — "this project is about making explicit what's usually tacit in your mental schema for X." It also names what's being lost in the formalization, which is honest.
Now a general-purpose vocabulary covering Person, Organization, Event, Book, Place, and hundreds more. Reuse target number one for new modeling work — if schema.org has a term for what you mean, use it. The canonical namespace is https://schema.org/ with the trailing slash; older tutorials use http:// and mixing the two in one graph creates two distinct URIs that look identical to the eye.
Output looks like a SQL result set: rows are matches, columns are projected variables. Most introductory SPARQL is SELECT plus a WHERE clause containing a basic graph pattern. The other query forms (ASK, CONSTRUCT, DESCRIBE) are specialized; SELECT is the workhorse.
The 2001 vision didn't materialize as advertised. Successes have been narrower than the framing suggested — life sciences (UMLS), finance (FIBO), government linked data, schema.org for SEO, Wikidata. "Semantic web" can mean (1) the original vision, (2) the W3C stack of standards built toward it, (3) the practitioner community. The curriculum uses sense (2) as default and treats the gap between vision and reality as a feature of the field worth knowing. The LLM moment is causing a renaissance, but the renaissance is graph-shaped, not necessarily RDF-shaped.
Core terms: skos:Concept, skos:broader, skos:narrower, skos:related, skos:exactMatch, skos:closeMatch. The right choice when the structure is taxonomic but not strictly class-based — concepts don't need disjointness, can be polyhierarchical, and don't carry the rigor of OWL classes. ESCO uses SKOS heavily, which is why Module 1's Resume Graph Explorer work makes the RDF case especially clean.
Four query forms (SELECT, ASK, CONSTRUCT, DESCRIBE) plus a separate update sublanguage. The syntax is small; the mental shift from SQL — pattern matching over a graph rather than relational joins — is the real lift. Most of SPARQL fluency is learning to think in basic graph patterns, then learning the modifiers that wrap them.
rdfs:subClassOf is transitive: if Genin subClassOf Ninja and Ninja subClassOf Character, then Genin subClassOf Character is inferred automatically. The foundational relation for taxonomic structure in RDFS and OWL ontologies. Most introductory ontology work is mostly subclass relationships plus a small number of properties.
Always a URI or blank node; never a literal. The role most likely to have a clear referent in the world — a person, an organization, a document, an event.
If senseiOf rdfs:subPropertyOf colleagueOf, then asserting :Jiraiya senseiOf :Naruto infers :Jiraiya colleagueOf :Naruto. Less commonly used than subClassOf but powerful for vocabulary alignment — when you want to map a specific property in one vocabulary onto a more general one in another.
(A, P, B) implies (B, P, A)
Declared via owl:SymmetricProperty. Useful for relations like :siblingOf or :marriedTo. Multiplies inferred triples — every asserted symmetric triple implies a second one. Performance gets pathological quickly with several symmetric properties on a large graph. Declare deliberately, not reflexively.
A subset of what ontologies do: taxonomies have subclass-like structure but typically lack restrictions, equivalences, or formal property semantics. Most "ontologies" referenced in marketing materials are taxonomies plus a controlled vocabulary. That's fine — taxonomies are useful — but the distinction matters when scoping work or estimating effort. A taxonomy can be built quickly; an ontology with restrictions and reasoning support cannot.
ontology (engineering)concept schemecontrolled vocabularySKOS
Rather than asserting :Naruto :rank :Genin as if eternal, introduce a Situation instance carrying :rank :Genin, :beginsAt 2003, :endsAt 2005. Verbose but honest about the temporal validity. The Ontology Design Patterns portal documents this formally; Module 2 reaches for it when modeling characters whose ninja rank changes across arcs. A specific case of n-ary relation.
(A, P, B) and (B, P, C) imply (A, P, C)
Declared via owl:TransitiveProperty. Useful for relations like :ancestorOf or :partOf. Computationally expensive — every transitive property requires the reasoner to compute the transitive closure across the graph. The "transitivity trap" is declaring transitivity reflexively (it feels right) and then watching reasoning slow to a crawl. Property paths in SPARQL 1.1 often replace the need for transitive declarations on the property itself.
The semantic-web equivalent of Postgres or Neo4j — except the market is sparse and no single product dominates. Fuseki (Apache Jena's HTTP server) is the de facto teaching default; Oxigraph is a lean Rust alternative for deployment; GraphDB and Stardog are commercial options with strong reasoning. Most triplestores expose SPARQL over HTTP, support some flavor of OWL reasoning, and accept Turtle for bulk loading. The lack of a Postgres-equivalent default is a real cost when scoping production work.
Each block of triples in a TriG file is wrapped with a graph URI: :myGraph { ... }. Reach for it when working with multiple named graphs in a single file, particularly for provenance and reification work. Most triplestores that read Turtle also read TriG.
Conceptually similar to a row in a three-column relational table, except every column position has constraints on what it can hold: subjects are URIs or blank nodes, predicates are URIs, objects are URIs or blank nodes or literals. The smallest unit of assertion the semantic-web stack works with. Everything else is triples plus structure.
?ninja schema:memberOf :Konoha . is a triple pattern with one variable (?ninja) and two fixed positions. Variables bind to URIs or literals during query evaluation. Triple patterns are the building blocks of basic graph patterns and, by extension, of nearly every SPARQL query.
Concise by design: prefixes shorten URIs, semicolons reuse the subject across predicates, commas reuse subject and predicate across objects, the a keyword stands in for rdf:type, blank nodes use square brackets. The curriculum uses Turtle for almost everything; only specific tasks (linked data on the web, JSON pipelines, native named-graph files) reach for other serializations.
Use it when the same conceptual property might be expressed using different vocabularies — name from foaf:name OR schema:name, for instance. Cheaper than running two separate queries and merging results in application code; more readable than collapsing the alternatives into a single complex FILTER.
Standard in databases — the primary key value uniquely identifies the row. NOT made by default in RDF: two distinct URIs might or might not refer to the same individual unless explicitly declared via owl:sameAs or owl:differentFrom. The consequence is that a reasoner can't conclude "X is not Y just because their URIs differ" — and applications that need this guarantee must assert it. Most clean RDF data implicitly relies on UNA without saying so, which works until it doesn't.
The naming primitive of RDF: every class, every property, and most instances get a URI. URIs in RDF don't need to resolve over HTTP, though Linked Data practice strongly recommends they do. The trailing slash, hash, and protocol all matter — http://schema.org/ and https://schema.org/ are distinct URIs that look identical to the eye and behave differently in a triplestore. URI versus IRI: IRIs allow Unicode; in casual writing the terms are used interchangeably.
FOAF, schema.org, SKOS, Dublin Core, PROV-O are all vocabularies. The line between "vocabulary" and "ontology" is fuzzy in practice — vocabularies tend to have lighter formal semantics, ontologies tend to carry more axioms — but the terms are used interchangeably in casual conversation. The senior move is to check whether a vocabulary already has a term for what you mean before defining a new one. Every custom term is a future maintenance burden and a missed interoperability opportunity.