Skilj objektet från typen av objekt.

AHU-3 är en entitet i en viss byggnad. brick:Air_Handling_Unit är en klass i Brick-ontologin. Den första är en instans; den andra ger en gemensam betydelse.

Skillnaden är lätt att formulera och lätt att sudda ut. En klass definierar en återanvändbar kategori. En instans identifierar den förekomst som applikationer, ritningar och källsystem refererar till. Mer specifika klasser kan öka precisionen utan att ändra förekomstens identitet.

Brick kan beskriva fysiska entiteter som fläktar och rum, logiska entiteter som HVAC-zoner och virtuella entiteter som datapunkter. De kan mötas kring samma aggregat utan att slås samman till ett enda objekt.

Klassificeringen talar om vad AHU-3 är. Relationerna talar om varför det spelar roll.

Öppna höljet med hasPart.

Sammansättning beskriver att en entitet innehåller eller består av andra entiteter. För AHU-3 kan brick:hasPart koppla aggregatet till dess tilluftsfläkt, värmebatteri, kylbatteri och filter. Den inversa relationen är brick:isPartOf.

Det är mer än en visuell gruppering. En underhållsapplikation kan fråga vilka komponenter som hör till ett aggregat, en analys kan hitta fläkten i enheten och en valideringsregel kan kontrollera att en överenskommen komponent är representerad.

Relationen bör återspegla den avsedda Brick-sammansättningen, inte importeras mekaniskt från en stycklista eller en aspektstruktur enligt IEC 81346. Dessa källor kan stödja påståendet, men deras relationssemantik är inte automatiskt identisk.

Ange vad det försörjer och var det finns.

brick:feeds representerar ett riktat flöde av något medium mellan entiteter. Relationer kan koppla AHU-3 till underordnad utrustning eller en betjänad zon när det är ett relevant påstående i modellen. Det är en semantisk topologirelation, inte ett sätt att modellera godtycklig fysisk luftflödesfysik, tryckfält eller varje kanalsträcka.

brick:hasLocation besvarar en annan fråga: var entiteten är placerad. AHU-3 kan finnas i ett fläktrum och samtidigt försörja utrustning och zoner på andra platser. Plats får inte ersätta försörjningstopologi.

Figuren är avsiktligt en delgraf. Den säger tillräckligt för att följa sammansättning, plats, telemetri och en vald försörjningsväg. Den påstår inte att noderna utgör en fullständig teknisk modell av AHU-3.

Koppla maskinen till dess punkter och roller.

brick:hasPoint länkar en entitet till en datapunkt som mäter, beordrar, anger börvärde för eller på annat sätt representerar en egenskap som är knuten till entiteten. Den inversa brick:isPointOf stöder sökning åt andra hållet. AHU-3 kan ha punkter för tilluftstemperatur, fläktkommando och filterlarm, klassificerade efter respektive roll.

Brick 1.5 introducerar också brick:hosts och brick:controls. Värdrelationen kan uttrycka att en entitet erbjuder exekverings- eller driftsättningsmiljö åt en annan. Styrrelationen kan ange att en entitet styr en annan. De ger användbart vokabulär, men bör bara anges när projektet kan belägga relationen.

Ingen lins ersätter de andra. En fläkt kan vara del av ett aggregat, en punkt kan vara knuten till fläkten, aggregatet kan finnas i ett rum och den sammansatta utrustningen kan ingå i en topologi nedströms.

Läs varje relation i dess angivna riktning.

Brick-relationer är riktade. AHU-3 brick:feeds VAV-3A är inte samma påstående som det omvända. Brick definierar inversa relationer för många vanliga predikat, exempelvis hasPart/isPartOf, hasPoint/isPointOf och feeds/isFedBy. Inferensverktyg kan materialisera inversa påståenden, men en fråga får inte vända en kant godtyckligt.

System, slingor och andra samlingar erbjuder ännu ett sätt att organisera sammanhang. Bricks modellering av samlingar låter entiteter ingå i en namngiven gruppering utan att påstå att samlingen är en fysisk behållare. Ett hetvattensystem, en luftkrets eller en ägardefinierad analyssamling kan vara en användbar frågepunkt när den modelleras med tillämpligt Brick-vokabulär.

En kantetikett utan riktning är bara ett halvt påstående.

Låt kompetensfrågorna dra gränsen.

En modell växer utan slut om ”fullständig” är det enda kravet. Kompetensfrågor ger ett skarpare kontrakt: konkreta frågor som grafen måste kunna besvara för den avsedda användningen.

• Vilka tilluftstemperaturpunkter hör till AHU-3?
• Vilka terminalenheter finns nedströms om AHU-3?
• Vilka zoner nås genom dessa enheter?
• Vilka fysiska komponenter ingår i aggregatet?
• Var är aggregatet placerat?
• Vilken extern identifierare leder till varje datapunkts data?

Frågorna definierar en första gräns kring AHU-3. Lägg till de entiteter och relationer som krävs för att besvara dem och testa sedan frågorna mot förväntade resultat. Ett senare användningsfall kan utöka grafen utan att den första leveransen behöver påstås representera varje kabel, kanal, styrsekvens och driftläge.

Ange vad som observerats, härletts eller refererats.

Ett grafpåstående kan se lika säkert ut i RDF trots att ursprunget skiljer sig radikalt. Ägarens styrning bör bevara skillnaden utanför eller tillsammans med de centrala Brick-påståendena.

Externa representationer gör inte Brick-grafen till källa för realtidsvärden. De hjälper en applikation att hitta en representation i ett annat system. Stabil grafidentitet, källsystemsidentitet, proveniens och giltighetsdatum bör vara tillräckligt uttryckliga för förändringsstyrning.

Resultatet är inte största möjliga graf. Det är en avgränsad, testbar och förklarbar delgraf där AHU-3 kan upptäckas som utrustning, följas genom delar och topologi, placeras i rummet, kopplas till datapunkter och relateras till externa data utan att rollerna blandas ihop.

En användbar graf säger inte allt. Den säger det viktiga, med ansvarstagande kanter.