Ett semantiskt gränssnitt är ett kontrakt, inte en ny monolit.

I produktion har Brick-grafen ett avgränsat uppdrag: att exponera gemensam betydelse och navigerbart sammanhang. Den kan tala om att SAT-3 är en tilluftstemperaturgivare som hör till AHU-3 och ge en referens som hjälper applikationen att hitta motsvarande representation i ett annat system.

Grafen behöver inte ta emot varje tidsserievärde eller bli vägen för styrkommandon. Fastighetsautomationssystemet, gatewayen, historikdatabasen eller dataplattformen kan förbli auktoritativ för dessa datamängder.

Bricks officiella dokumentation om programvarugränssnitt beskriver sätt att arbeta med grafdata, men Brick föreskriver inte ett standardiserat API för att hämta varje extern datamängd. Begreppet gränssnitt är användbart bara när den gränsen är tydlig.

Grafen svarar på ”vad ska jag fråga efter?” Källsystemet svarar på ”vilket värde har det nu?”

Låt SPARQL hitta källorna och deras sammanhang.

SPARQL söker efter grafmönster i stället för lokal taggsyntax. En applikation kan fråga efter luftbehandlingsaggregat, deras tilluftstemperaturgivare och de externa representationer som är kopplade till punkterna.

Frågeresultatet bör returnera identiteter och metadata, inte låtsas innehålla den aktuella temperaturen. En BACnet-referens kan identifiera enhet, objekttyp och objektinstans. En tidsseriereferens kan identifiera databas, ström eller samling enligt den externa representation som används.

Applikationen behöver fortfarande en anslutning som förstår den refererade plattformen. Brick standardiserar användbar betydelse i grafen; modellen tar inte bort de operativa skillnaderna mellan BACnet, en historikdatabas och en molnbaserad tidsserietjänst.

Skilj upptäckt från hämtning.

Ett robust flöde från fråga till data har synliga överlämningar. Varje steg kan misslyckas oberoende och bör ge diagnostik som visar om problemet gäller semantik, referens, anslutning eller drift.

Separationen skyddar ägargränserna. Ett byte av historikdatabas kan kräva uppdaterade referenser och anslutningar utan att den semantiska frågan behöver skrivas om. En förfinad graf kan förbättra upptäckten utan att tidsserielagret flyttas.

Driftsdesignen måste också definiera beteendet vid saknade referenser, inaktuella identifierare, nekad åtkomst, timeout, kvalitetsflaggor och enhetshantering. Semantik minskar tolkningsarbetet; den tar inte bort operativ felhantering.

Använd SHACL som en grind, inte en slogan.

Brick publicerar SHACL-former, och verktyg med SHACL-stöd kan validera grafdata mot dem. En driftsättning kan också lägga till ägardefinierade former för projektkrav: obligatoriska punkter, tillåtna utökningar, identifierarmönster eller relationer som en applikation behöver.

Validering bevisar inte att en relation är sann i den fysiska byggnaden. Den testar den levererade grafen mot angivna begränsningar. Ett aggregat kan klara en strukturell form och ändå vara kopplat till fel givare om källevidensen eller mappningen var fel.

Behandla valideringsprofilen som en versionshanterad leverans. Registrera vilka former som kördes, vilka allvarlighetsgrader som stoppar en release, hur undantag godkänns och vilken grafversion som gav rapporten.

Gör underförstått beteende till ett uttryckligt driftsättningsval.

Brick-inferens kan lägga till användbara påståenden, bland annat typer från överklasser, inversa relationer och taggar. En punkt som typats som en specifik tilluftstemperaturgivare kan också kännas igen genom bredare klasser; en angiven feeds-kant kan ge sin invers; klassdefinitioner kan bidra med taggar.

Inferens är inte ett strikt krav för att använda Brick. En driftsättning kan fråga endast efter uttryckliga påståenden, resonera vid inläsning, materialisera en infererad graf eller resonera när frågan körs. Valet påverkar frågeresultaten och måste ingå i kontraktet.

Ontologiversionen måste också vara uttrycklig. Importera den avsedda Brick-releasen genom en godkänd, reproducerbar mekanism och registrera den ontologi-IRI och versionsinformation som användes för att bygga och validera grafen. Följ inte tyst ett ofixerat ”senaste” beroende i produktion.

Om slutledning ändrar svaret är slutledningen en del av gränssnittsversionen.

Utöka lokalt utan att förgrena det gemensamma språket.

Projekt behöver ibland begrepp som inte representeras med önskad detaljnivå i Brick. En lokal namnrymd kan definiera ytterligare klasser eller egenskaper och relatera dem till Brick när det är semantiskt motiverat. Utökningen bör vara tydligt lokal, dokumenterad och testbar.

Skapa inte ett nytt predikat bara för att teamet inte hittar det officiella, och omdefiniera inte en officiell Brick-term så att den betyder något projektspecifikt. Sök först i aktuell ontologi och dokumentation. När en lokal term behövs ska definition, ägare, status, förväntad domän/räckvidd och migreringsplan anges.

Proveniens kan hanteras i en graf, ett releasemanifest, en datakatalog eller ett styrt arkiv. Mekanismen är mindre viktig än förmågan att svara på: vem gjorde detta påstående, från vilken evidens, genom vilken omvandling och under vilken godkänd version?

Externa referenser kräver samma disciplin. En ändrad BACnet-objektinstans eller tidsserienyckel är en gränssnittsändring även när den semantiska entiteten fortfarande är AHU-3.

Acceptera gränssnittet med tester och en namngiven ägare.

En syntaktiskt giltig RDF-fil är inte ett accepterat semantiskt gränssnitt. Acceptansen bör prova de beteenden som konsumenterna är beroende av, med representativa data och förväntade resultat.

Ägarskapet sluter kontraktet. En namngiven ägare godkänner ontologiuppgraderingar, lokala utökningar, undantag, referensändringar och releasetidpunkt. Producenter vet vad de ska leverera. Konsumenter vet vilken version och vilket beteende de kan lita på. Driften vet hur en trasig referens eller inaktuell graf rättas.

Här blir datastyrning konkret: inte ett policydokument bredvid grafen, utan beslut inbyggda i releaser, tester och ansvar.

En semantisk modell blir ett gränssnitt när någon äger löftena den ger.