The T-Box, part 2: properties and the c360 ontology (OWL)

One line in an ontology can look like a check but isn't. Take :purchasedBy rdfs:domain :Order. A property's domain is the kind of thing the property is used on: the subject, the left-hand side of the triple (Section 6.2 covers it properly). The line reads like "only orders can have :purchasedBy." What it actually tells Stardog is: "if something has :purchasedBy, label it an Order." So if bad data says Wax Paper :purchasedBy Carolyn, Stardog doesn't refuse it. With reasoning on, it quietly labels Wax Paper an Order. That is wrong: Wax Paper is a product. This chapter shows why it happens, how the c360 kit avoids it, and ends with the full ontology (161 triples) loaded as build step 2.

6.1Properties: the columns and foreign keys of a graph

The ten classes from Chapter 5 have no columns: our :Customer has no name, no email, no address. That is deliberate. In a graph, columns and foreign keys are played by a property: anything used as the predicate of a triple, such as :firstName or :purchasedBy. A property has its own IRI and is declared on its own, outside any class, so that many classes can share it and the model can say things about the property itself (its label, what it connects). OWL splits properties into two kinds:

• An object property (owl:ObjectProperty) links a thing to another thing, an IRI you can keep following. order :purchasedBy customer:225. This is your foreign key.
• A datatype property (owl:DatatypeProperty) links a thing to a literal (string, number, date). customer:225 :firstName "Carolyn". This is your plain column.

Where does the real c360 vocabulary come from? The c360 knowledge kit (Chapter 1) ships its whole ontology as one Turtle file, schema.ttl, in Stardog's public GitHub repository: https://github.com/stardog-union/knowledge-kits/blob/main/examples/c360/models/schema.ttl. You'll load all of it at the end of this chapter. Here is its entry for :firstName, unchanged:

:firstName a owl:DatatypeProperty ;
    rdfs:label "first name" ;
    so:domainIncludes :Customer ;
    so:rangeIncludes xsd:string .

The last two lines say which class the property is used on (Customer) and what kind of value it takes (a string). so: is short for schema.org, a shared vocabulary for describing data on the web. The textbook way to write these two facts is rdfs:domain and rdfs:range, but that way has a trap (the Wax Paper problem from the opening). Sections 6.2 and 6.3 show the trap and why the kit uses so: instead.

6.2rdfs:domain and rdfs:range: rules, not checks

RDFS describes a property with two statements. Here they are for :purchasedBy, written the textbook way:

:purchasedBy rdfs:domain :Order ;
             rdfs:range  :Customer .

The semicolon makes this two triples, and the subject of both is the property itself, :purchasedBy. So these are facts about the property, not about any particular order or customer:

To read them, picture a real data triple that uses the property:

order:0e7e…   :purchasedBy   customer:225
 left side                   right side

• rdfs:domain :Order says the left side of a :purchasedBy triple is an Order.
• rdfs:range :Customer says the right side is a Customer.

In plain words: "purchasedBy goes from an Order to a Customer." Every SQL person reads that as a check: "only orders may have :purchasedBy, and its value must be a customer." That reading is wrong, and why is the most useful idea in this chapter.

With reasoning on, Stardog doesn't check these two statements; it applies them. Whatever appears on the left of a :purchasedBy triple gets labelled an Order, and whatever appears on the right gets labelled a Customer.

Nothing is ever rejected. In an open world (Chapter 5) the reasoner assumes the data is right and the type merely unstated, so it fills it in.

It gets worse when a property is shared, like the kit's :name. Written with rdfs:domain:

:name rdfs:domain :Category, :Customer, :Product, :Vendor .   # do NOT do this

Several domains do not mean "one of these". Each is its own rule and each fires, so every named thing becomes a Category and a Customer and a Product and a Vendor; Carolyn would become a product. (The formal fix, an owl:unionOf class as the domain, is heavy and still an inference rule, not a check.)

6.3so:domainIncludes and so:rangeIncludes: the kit's answer

The c360 kit avoids the trap by not using rdfs:domain and rdfs:range at all. It uses two predicates from schema.org (prefix so: = https://schema.org/), the search engines' vocabulary for describing web content:

• so:domainIncludes: "this property is expected on things of this class." Several values mean "any of these", which is what people mean.
• so:rangeIncludes: "values are expected to be of this class or datatype."

The key word is expected. These predicates have no formal meaning in RDFS or OWL, so Stardog's reasoner draws no conclusions from them. :name so:domainIncludes :Category, :Customer, :Product, :Vendor says what the modeler meant, and reasoning in Chapter 10 will never make Carolyn a product.

They are documentation that machines can read. Stardog Designer writes them when you draw a property between two classes, and model views use them to show which properties belong to which class. Voicebox and your agent read them when writing SPARQL; :name so:domainIncludes :Category, :Customer, :Product, :Vendor is exactly the hint that :name can appear on a category, a customer, a product or a vendor, so a question like "what is customer 225's name?" is answered with :name. (How each tool uses them internally is up to that tool; if a view looks empty, tell Claude.)

6.4owl:inverseOf, and a wrinkle in the kit

Every relationship reads two ways: "order purchased by customer" is also "customer placed order". SPARQL can already walk an arrow backward (?order :purchasedBy customer:225), but sometimes you want a name for the reverse direction. owl:inverseOf says two properties are one relationship read in opposite directions. A correct example (not in the kit): :placedOrder owl:inverseOf :purchasedBy. With that line in the model, order:0e7e… :purchasedBy customer:225 also means customer:225 :placedOrder order:0e7e…: the same fact, read from the other end.

An inverse must swap the two ends. Now read what schema.ttl actually says:

:rewardsAccountUsed a owl:ObjectProperty ;
    owl:inverseOf :hasRewards ;
    so:domainIncludes :Order ;
    so:rangeIncludes :RewardsAccount ;
    rdfs:label "rewards account used" .

:hasRewards a owl:ObjectProperty ;
    owl:inverseOf :rewardsAccount ;
    so:domainIncludes :Customer ;
    so:rangeIncludes :RewardsAccount ;
    rdfs:label "has rewards account" .

Both owl:inverseOf triples deserve a raised eyebrow. :rewardsAccountUsed goes Order → RewardsAccount and :hasRewards goes Customer → RewardsAccount: both point at the account, so they are not each other's reverse. Taken literally with reasoning on, "order O used account R" implies "R has rewards O". The second, :hasRewards owl:inverseOf :rewardsAccount, is sensible in intent (the account points back at its customer), but :rewardsAccount is declared nowhere and no mapping produces it; the open world allows that.

We load the kit exactly as shipped, because the rest of the book assumes that file, and with reasoning off (until Chapter 10) inverse axioms have no effect. The practical risk is contained but real: 1,560 of the 2,500 purchases carry a rewards account (none of Carolyn's do), so with reasoning on under this schema each of them yields a bogus inferred triple, and a query that also requires ?c a :Customer filters those rows out. Chapter 10 shows how to spot them. The lesson: an ontology is code, and code has bugs. If rewards accounts ever show up where customers should be in a reasoning query, look here first.

6.5The whole c360 ontology

You can now read every line of schema.ttl: 10 classes, 11 object properties and 22 datatype properties. Figure 6.3 draws the classes and relationships.

The 11 relationships

Two graph habits hide in that table. :hasRewards points from customer to account, the opposite of the SQL foreign key: modelers choose the direction that reads best as a sentence. And :msrp points at a UnitPrice node carrying a price and a currency, not a bare number: a value turned into a thing so it can hold more facts.

The 22 attributes

• ★ Sensitive. :ssn and :cardNumber carry a second type, m:SensitiveProperty (prefix m: = urn:stardog:modules:): a "treat as sensitive" marker. Chapter 12 covers how Stardog can act on it, and why the book keeps PII in a separate, permissioned graph.
• Money. :purchasePrice is described as decimal, :hasPrice as float. so:rangeIncludes is only a description, so the mappings decide the real datatype; Chapter 9 explains why spend must come from the decimal.

6.6What the ontology does not contain

Notice what schema.ttl does not mention: Aurora, Redshift, table or column names, cid, connection strings, SQL. It does not know there are 2,500 orders, or contain a single customer. It is purely a description of meaning: these kinds of things exist, and this is how they relate.

That separation is the point. Connecting meaning to where the data lives is the job of the mappings (Chapter 8 for Aurora, Chapter 9 for Redshift): "each row of c360.customer is a :Customer, and its first_name column is :firstName". Swap Redshift for Snowflake tomorrow and not one triple of the ontology changes; only a mapping does.

The flip side: model and mappings can drift apart, and the open world will not warn you. The Redshift mapping writes a vendor :homepage the ontology never declares, and no mapping produces the declared customer :thumbnail. A declaration is a promise of meaning, not a guarantee of values.

6.7OWL versus RDFS on one page

Stardog lets you choose how much of OWL its reasoner applies. The default setting (called SL) covers the everyday parts you've met in this book, such as subclasses, inverses, and domain and range, and it also runs Stardog's own IF/THEN rules, like "big spender" (Chapter 10). You never need to change that setting for this book. In one line: RDFS names kinds of things and arranges them in hierarchies, OWL says more precisely how things relate, and neither one checks your data.

6.8Real build step 2: the complete ontology

Four parts: A adds three properties by hand, B loads the whole schema.ttl on top, C registers the model graph as a reasoning schema, D looks at the result in Studio. Everything goes into database kit-c360, graph <urn:stardog:training-c360:1.0:model>, the same graph as Chapter 5. Keep the reasoning toggle off throughout.