The T-Box, part 1: classes (RDFS)

Imagine inserting one triple saying that Carolyn Inworth's shoe size is 38. There is no shoe-size property anywhere, no class that mentions shoes, no schema at all. Stardog says "OK" and stores it. Try that in Aurora (UPDATE customer SET shoe_size = 38 WHERE cid = 225) and Postgres stops you cold: column does not exist. Your instinct says the graph is being sloppy. By the end of this chapter you will see that it is deliberate, that this choice is what makes a semantic layer over many databases possible, and where to go when you do want the database-style "no". Along the way you will write the first ten classes of the real c360 model: build step 1.

5.1Schema and data: the T-Box and the A-Box

So far every triple you have written was about one particular thing: Carolyn's email, the price of one order. Knowledge-graph people split triples into two families:

• The T-Box ("terminology box") holds triples about kinds of things: "there is a class called Customer", "an Order is purchased by a Customer". It is the schema.
• The A-Box ("assertion box") holds triples about particular things: "customer 225 is a Customer", "customer 225's first name is Carolyn". It is the data.

Why new names for "schema" and "rows"? Because in a graph they are made of the same stuff: both are triples, both sit in named graphs, both are queried with the same SPARQL. The names say which role a triple plays. The whole T-Box for a domain is an ontology (Stardog's tools also call it a model): one shared, machine-readable vocabulary for an organization. The single triple :Customer a owl:Class is already a very small ontology. Chapters 2 to 4 were A-Box work; this chapter and the next are T-Box work.

5.2RDFS and OWL: why there are two schema languages

RDFS (RDF Schema, prefix rdfs: = http://www.w3.org/2000/01/rdf-schema#) came first (W3C, 1999 to 2004), because plain RDF can state facts but cannot say what kinds of things exist. It adds the bare minimum: classes, subclasses, labels, comments, and a way to say which classes a property connects. Tiny example: :Customer a rdfs:Class ; rdfs:label "Customer" .

OWL (the Web Ontology Language, prefix owl: = http://www.w3.org/2002/07/owl#; the letters are deliberately shuffled) followed in 2004, with OWL 2 in 2009. OWL is built on top of RDFS: everything RDFS says still holds, and OWL adds more precise statements. Three of them, each with our data (the property :placedOrder and the CRM name are hypothetical; the rest is real):

RDFS alone can say none of these three things. It knows that a Customer is a kind of thing and that one kind sits under another, but not reverses, exclusions or aliases. The tiny example :Customer a owl:Class . declares a class exactly as rdfs:Class does; for this book the two are interchangeable. The difference is in the extra statements OWL makes possible, like the three above.

RDFS is the foundation, OWL the extension, and real ontologies mix both. The c360 kit declares classes with owl:Class (every OWL class is also an RDFS class) and labels them with rdfs:label. Chapter 6 ends with a one-page comparison once you have seen properties too.

5.3Classes and rdf:type

A class is a named set of things: all customers, all orders. You declare one by giving its IRI a type of its own, and connect a thing to it with rdf:type, the predicate you have been typing as a since Chapter 3:

:Customer a owl:Class .                            # T-Box: Customer is a class
<urn:stardog:demos:c360:customer:225> a :Customer .   # A-Box: 225 is a Customer

The class declaration has no column list. A class does not own properties the way a table owns columns; properties are declared separately and point at classes (Chapter 6). And because rdf:type is just a triple, you get freedoms a table never gives you:

• A thing can have several types. In Chapter 10 Carolyn will be both :Customer and :Big_Spender, and nobody will have stored the second one.
• A thing can have no type at all. Chapter 4's Queries 3 and 5 would have worked even without the a :Customer triples, because they only followed properties.
• Types can be added later, by anyone, in any graph, with no ALTER TABLE.

By convention class names are capitalized (:CreditCard) and properties are not (:firstName). Nothing enforces it; everyone relies on it.

Now the labels. rdfs:label gives a human-readable name ("Credit Card") and rdfs:comment a description (the kit's "A concept representing a Customer's rewards account."). They look like decoration but are load-bearing: when Voicebox (Chapter 13) or your agent (Chapter 14) turns "Who are our top spenders in Wisconsin?" into SPARQL, labels and comments are much of what the language model reads to decide which class "spenders" means.

5.4Subclasses: inheritance you get for free

rdfs:subClassOf says every member of one class is also a member of another. This triple is real; it is in the kit's extended model, which you load in Chapter 10:

:Big_Spender rdfs:subClassOf :Customer .

The pay-off is inference: a new fact concluded from existing ones. Given customer:225 a :Big_Spender, a reasoner concludes customer:225 a :Customer, although nobody stored it.

Two practical notes. Inference happens only with Studio's reasoning toggle on, and it stays off until Chapter 10. And inferences are computed at query time, never written to disk, so they cannot go stale; that is why reasoning works over virtual graphs, whose data is not in Stardog at all. The base c360 schema has no subClassOf triples: ten flat classes cover the core questions, and the hierarchy arrives with the business rules in Chapter 10.

5.5The open-world assumption

Back to Carolyn's shoe size: this is the mindset shift of the book. Every database you have used runs on the closed-world assumption: the database is the complete record of its slice of the world. No order row for customer 225 in March means she ordered nothing in March; a bad foreign key is rejected at the door. Absence means "false", and the schema is a contract data must pass to get in.

RDFS and OWL run on the open-world assumption: a graph is what is known, never a claim to know everything. A missing triple means "not stated here", not "false". No phone triple for Marlane does not mean she has no phone (she has one; you left it out in Chapter 4).

Four consequences, from most to least surprising:

1. The schema does not reject data. Nothing stops an undeclared property, a customer with three emails, or an order with no customer. RDFS and OWL have no NOT NULL, no CHECK, no foreign keys.
2. Where SQL raises an error, a reasoner draws a conclusion. The reasoner fills gaps instead of refusing. Chapter 6 shows the famous case: tell it that only orders are "purchased by" someone, feed it a buggy triple, and it concludes that a box of Wax Paper is an order.
3. Different names are not assumed to be different things. Two IRIs might name the same customer. Ours are built from the same keys on both sides (the "IRI trick", Chapter 9), so this rarely bites.
4. Queries still answer from what is there. SPARQL evaluates patterns over the triples it has: FILTER NOT EXISTS { ?c :phone ?p } returns customers with no phone triple, a perfectly closed-world answer. The open world does not change how SPARQL runs; it changes how you read the result ("no phone triple in the graphs we queried") and what the reasoner may conclude. Recall Chapter 4's Query 5, where Marlane "outspent" Carolyn only because we loaded two orders each.

Why build it this way? Because the open world is the honest assumption when data comes from many places. Aurora does not "know" that a customer has no orders; orders are not its job. A closed-world schema over Aurora and Redshift would either reject good data or lie about completeness. A semantic layer describes data it does not own. The price: validation becomes a separate, explicit step.

5.6Where the c360 model lives

The model gets its own named graph, <urn:stardog:training-c360:1.0:model>, in the kit-c360 database (the name comes from the c360 knowledge kit; 1.0 is a version). A separate graph pays off three times: in Chapter 6 you register it as the reasoning schema; from Chapter 8 on the data stays in Aurora and Redshift, so this graph (plus Chapter 10's rules) is all that is physically stored in Stardog; and in Chapter 12 named graphs are the unit of permission, so everyone can read the model even when they cannot read the PII.

5.7Real build step 1: the ten classes

This is not scratch work: these triples start the model the reasoner, Voicebox and your agent will use. They are word for word the class declarations in schema.ttl, the c360 kit's ontology: one Turtle file holding the whole vocabulary, 161 triples, published in Stardog's public GitHub repository (https://github.com/stardog-union/knowledge-kits/blob/main/examples/c360/models/schema.ttl). Loading the full file in Chapter 6 creates nothing different.