Define the vocabulary that describes your domain

Each dataspace has a namespace ontology where you define the classes and properties of your domain. It lives in the admin dataspace, which shares your base URI with\n an admin. subdomain prefix: for the end-user app at https://localhost:4443/, the ontology document is\n https://admin.localhost:4443/ontologies/namespace/.

Northwind reuses Schema.org terms rather than inventing its own, so modeling here means little more than declaring which classes the app\n uses and how they are labeled:

@prefix :       <#> .\n@prefix rdfs:   <http://www.w3.org/2000/01/rdf-schema#> .\n@prefix owl:    <http://www.w3.org/2002/07/owl#> .\n@prefix schema: <https://schema.org/> .\n\n: a owl:Ontology .\n\nschema:ProductGroup a owl:Class ;\n    rdfs:label \"Category\" ;\n    rdfs:isDefinedBy : .\n\nschema:Product a owl:Class ;\n    rdfs:label \"Product\" ;\n    rdfs:isDefinedBy : .\n\nschema:Order a owl:Class ;\n    rdfs:label \"Order\" ;\n    rdfs:isDefinedBy : .

Source (full model): admin/model/ns.ttl

The finished model goes further than labels. It declares the domain's properties with their domains and ranges, a couple of owl:Restrictions,\n and a constructor that drives the Product create form.

It also attaches views directly to properties with ldh:inverseView. That is why every customer page shows its orders and every supplier page its\n products, with no per-page configuration.

\n \n \n

Open the admin dataspace and edit the namespace ontology document directly, or follow the Change model guide, which also\n shows how to add SPIN constructors to classes — the templates that drive the create-instance forms in the UI.

Append the class definitions from ns.ttl to the namespace ontology document with POST. The prepended @base makes the : prefix resolve to\n ${LDH_BASE}ns# — the terms belong to the end-user namespace even though the ontology document lives in the admin app:

admin_base=\"https://admin.localhost:4443/\"   # $LDH_BASE with the admin. subdomain prefix\n\n{ echo \"@base <${LDH_BASE}ns> .\"; cat ns.ttl; } | ldh post \\\n    -t text/turtle \\\n    \"${admin_base}ontologies/namespace/\"

The ontology is cached in memory, so tell the dataspace to reload it:

ldh admin clear ontology \\\n    -b \"$admin_base\" \\\n    --ontology \"${LDH_BASE}ns#\"

What you now see

The ontology document in the admin app now renders your classes with their labels. The visible payoff on the end-user side comes in the next stage: resources imported as\n schema:Product or schema:Order arrive typed and labeled, and the model is what the UI uses to render and create them.

How this works

Ontologies — namespace ontologies, imports and caching
Change model — classes, constructors and constraints from the UI

Next: Data