Present Northwind as a business application, and fix its schema.org modelling

[namedgraph]

Makes the Northwind demo read as a business application rather than an RDF data browser, and puts its data in schema.org terms that actually hold.

No CSV is modified anywhere on this branch. Everything the mappings emit is derived from stock Northwind columns — order status from shipped-vs-required date, line totals from quantity × price × discount, dispatch dates from shippedDate.

Presentation

• The frontpage no longer advertises LinkedDataHub's feature list or the low-code build story
• The dashboard leads with the monthly sales trend instead of a two-value table stretched over the 400px chart canvas
• Record lists come before analytics in each container, so a section opens on its data
• Suppliers, shippers, regions and territories get the narrative intros the other containers already had
• dct:title on every ldh:Object block. Without it the block heading renders the fragment identifier, so pages were showing kpi-block and select-suppliers as headings
• Northwind's own vocabulary in the ontology: Sales rep rather than Broker, Reports to rather than Sponsor, Territory, Region, Company name, Required by
• .ldh-section for section headers; page-header and lead are Bootstrap 2 leftovers with no rules in the current design system

schema.org modelling

Several properties were carrying values outside their declared domains. Each moves to the term the vocabulary actually provides:

was	why it was wrong	now
OrderItem schema:price, schema:totalPrice	schema:OrderItem has no price properties at all — only orderedItem, orderQuantity, orderItemNumber, orderItemStatus, orderDelivery	the line is schema:OrderItem, schema:Offer; Offer.price is the price of the offer as a whole, i.e. the line total
unit price on the line	nowhere legal to put it	schema:priceSpecification → schema:UnitPriceSpecification with schema:priceType schema:ListPrice
OrderItem schema:discount	schema:discount is an Order-level property, and means an amount rather than a rate	dropped — list price, quantity and line total pin the rate exactly, and unlike a stored rate they cannot disagree
Product schema:price	schema:Product has no price either	schema:offers → schema:Offer
ParcelDelivery schema:price (freight)	schema:ParcelDelivery has no price	schema:priceSpecification → schema:DeliveryChargeSpecification from a shipping schema:Offer
ParcelDelivery schema:availableFrom (shipped date)	a DeliveryEvent property borrowed onto a delivery, and it means "available for pickup", not "dispatched"	schema:deliveryStatus → schema:DeliveryEvent with schema:startDate. Orders never dispatched get no event at all
schema:orderedItem domain/range	narrowed to Order → Product, which entailed every OrderItem is a Product	left unconstrained; schema.org allows Order|OrderItem → OrderItem|Product|Service, which one domain/range pair cannot express

Currency is hardcoded "USD" throughout, since Northwind has no currency column.

Analytics

orderStatus, the materialised line total and the dispatch date make four new charts possible, each with a narrative block ahead of it:

• Discount rate by month (frontpage) — the gap between catalogue and billed price, 3.6%–11.2% of gross and decorrelated from volume, which a revenue chart cannot show
• Days to ship (orders) — order to dispatch, averaging 8.5 days
• Shipped on time (orders) — share of orders beating the promised date, 91.2%–100%
• Late shipments by carrier (orders) — 5.1% / 4.9% / 3.6%, so carriers are compared on reliability as well as volume

Both rate charts are normalised deliberately. Raw monthly status counts squash the late series (0–4 a month) against a delivered series climbing 21 to 69, and the 21 still-open orders are a dataset-cutoff artifact confined to the last two months — they are filtered out, since not yet dispatched is not the same as delivered late.

Orders by country is dropped to make room: the frontpage already tells the geographic story in revenue rather than order count, the more useful of the two measures.

First multi-series chart

Revenue by carrier on the Orders page plots three carriers over 22 complete months. Each ldh:seriesVarName names its own measure column, so the query pivots with conditional aggregation. The sales-by-region-per-year chart removed earlier passed a label column plus a value column, which is why it never rendered — and region was the wrong dimension anyway, since sales reach a region only through employee → territory and 9 employees hold 49 territory-region pairs, double-counting anyone who serves two.

Correctness

• Records were being dropped at import on empty postal codes. shipPostalCode sat in the required BGP of orders.rq but is empty for 19 rows, so those orders never entered the graph — 811 → 830 orders, and revenue 1,215,812 → 1,265,792, which is Northwind's canonical Order Subtotals figure. customers.rq had the same bug: HUNGO (Hungry Owl All-Night Grocers, Cork) has no postal code, because Ireland had none until Eircode in 2015, so the whole customer was discarded and its 19 orders were left with a schema:customer link resolving to nothing. Both columns move to OPTIONAL, and dangling customer references go from 19 to 0. An audit of all eleven mappings against their CSVs confirms these were the only two required-but-sometimes-empty columns
• Revenue charts are net of discount. They had summed quantity × price, overstating by 6.7%. All six now read the materialised line total directly instead of each recomputing it, so they also agree with one another rather than differing by rounding
• The truncated final month is excluded from the trend. Data stops on 1998-05-06, which rendered as a collapse rather than a partial month. The cutoff derives from MAX(?orderDate) rather than a pinned date
• No hardcoded counts in prose
• A Revenue by category chart duplicated in products.ttl is removed; it belongs to categories.ttl

Verified by running all eleven import queries over the real CSVs and all 31 view and chart queries against the resulting graph: 830 orders, 2155 line items, freight totalling 64,943, and top product / employee / customer / category all matching canonical Northwind.

Known issues, not addressed here

• Re-importing duplicates line items. order_details.rq writes many rows into one order graph; add() PUTs with If-None-Match: * and POSTs on 412, so a second run appends to the existing graph, and STRUUID() identities mean it never converges. Northwind must be purged before each import. This looks like a LinkedDataHub bug affecting any mapping that writes several rows to one graph
• The line-items table lost its unit price and discount columns. Table columns come from the resource's own predicates, and the unit price now lives on a nested UnitPriceSpecification, so it is one click away rather than in the table. This is the direct cost of schema.org having no per-line unit-price slot
• A View cannot show an aggregate. ldh:View wraps its SELECT as DESCRIBE * WHERE { … }, so an aggregate binds to a literal and vanishes before rendering. The order list therefore has no order-total column
• Property labels only resolve client-side. SSR passes object-metadata but never property-metadata, so a hard load shows OrderDate where in-app navigation shows Order date