Enne tarkvaraliste näidete juurde asumist (kuidas nendega tagada RDS/CCI põhimõtteid), vaatame üldistavalt, kuidas ühtse klassifitseerimissüsteemi kasutuselevõtmine aitab kujundada varakeskset unikaalset ID-d, mis on elukaareülene ning nii inim- kui masinloetav. Juhul kui varasemalt on kasutusel mõni muu unikaalse ID kasutamine, tuleb see siduda RDS/CCI koodidega, mida siinkohal ei käsitleta. Üldistavalt saab märkida, et mistahes IT süsteem võib kasutada oma enda unikaalset ID väärtust ja me ei pruugigi saada seda selles tarkvaras ümber defineerida (võtame näiteks BMS ehk Building Management System, mõne turvasüsteemide lahenduse, ruumiregistri, vararegistri jne – kõigis neis võib olla defineeritud oma enda unikaalse ID loogika, mõnes näiteks vaid numbrite kujul). Seega peame digitaalehituse kontekstis või siis ka sellest tuleneva varade korrashoiu kontekstis teostama informatsiooni omavahelise integreerimise, kus ehitusinfost tulenev ja näiteks RDS/CCI klassifitseerimissüsteemil baseeruv unikaalne ID seotakse teiste, tellijale oluliste, infosüsteemidega. Kui seda unikaalset ID-d aga ehitusinfo kontekstis pole, on ka integreerimisi ülikeeruline teostada. Tarkvarade vaikimisi unikaalsed ID-d (GUID, Element ID, Handle jne) ei ole inim- ega masinloetavad, lisaks kasutavad erinevad tarkvarad erinevat unikaalset ID-d ja samalaadse info ülekandmisel peame tegema kordades rohkem erinevaid integreerimisi.

Infosüsteemide ülese unikaalse ID kasutuselevõtmine muutub kriitiliseks kui meil on soov liikuda mudelpõhisesse korrashoidu, kus muuhulgas tuleb defineerida ka optimaalsed infoedastuse ülekanded (EIR ehk Exchange Information Requirements nii nagu seda sätestab EN ISO 19650 standardite seeria). Samas on oluline rääkida ühtsest unikaalsest ID mõistest (inim- kui masinloetav) mistahes ehitise elukaare etapi juures, kus on vaja teha kokkuvõtteid või väljavõtteid mahtudest (kas siis ehitusinfomudelist või sellega seotud dokumentatsioonist), millel seejärel baseeruvad näiteks nii eelarved kui muu info automaatne kaasamine. RDS/CCI võimaldab tekitada automaatseid seoseid teiste, CCI-EE alamtabelitega, nt teatud ehituskomponentidega seotakse kindlad abivahendid/ressursid või tegevused. RDS/CCI annab võimaluse rääkida mahtudest nii üldisemal tasandil (rahvusvaheline mõõde) kui siis ka detailsemas esituses, milles kaasatakse juba RDS/CCI rakendustabeleid (RDS/R), kus lisaks üldtaseme koodile tuuakse sisse ka tüübi/alatüübi kontekst. Pane tähele, et RDS/R rakendustabelid (tüübid/alatüübid) on RDS/CCI tuumiktabelite lisa, mis on omaette arendus ja mida siinkohal näitena ka põgusalt esitletakse.

Klassifitseerimine tähendab üldjuhul mingite kindlate atribuutide defineerimist, nende kasutusele võtmist digitaalse / füüsilise vara kontekstis. Need atribuudid peaksid olema selgelt defineeritud ja ka nimetatud, alles siis saame nende kaudu edastatavast omadusest üheselt aru (atribuudi mõiste = omaduse nimetus, mis kannab endas omaduse väärtust). Siinsetes näidetes kasutame CIA-DD atribuutide gruppe/loogikat.

CIA-DD tabelites on ühtne struktuur tagatud läbi atribuudi koodi (2 tähte + 3 numbrit), mis peab jääma paika mistahes rakenduses kui soovitakse CIA-DD tabelist lähtuvat ja ühetaolist infovahetust. Üldjuhul koosneb meie atribuudi nimetus aga lisaks ka tekstilisest kirjest, mida CIA-DD tabel üheselt ette ei kirjuta ja mida võib seega ka projekti- või tellija põhiselt määratleda. Seetõttu ongi siinne näide üks võimalikest nimetamise skeemidest. Ehkki tekstiline kirje on justkui vaba, peab see jääma atribuudi koodi/ definitsiooni/ standardi poolt määratud piiridesse ja ei tohiks olla segadust tekitav. Atribuudi koodile (kui seda kasutatakse mõnes rakenduses) võib lisada viite CIA-DD tabelile, kust saab lugeda täpsustavat infot antud atribuudi kohta. Selliselt hallatakse atribuutide definitsioone ühest kindlast kohast, kust võib omakorda leida seoseid teiste infosüsteemidega (nt IFC property, ETIM kood jne).

Antud näites piirdume RDS/CCI tuumiktabeleid määratlevate atribuutidega + tüübi ja ID-ga seotud lisaatribuudid. Samas on võimalik tekitada ka laiendatud vaade, kus kaasatakse nn CCI-EE kollaste/punaste tabelite atribuutinfot. Tasub aga rõhutada, et tuumiktabelite atribuudid on kõige määravamad ning kogu atribuutinfot ei peagi mudelisse kaasama. Tänu tuumiktabelite atribuutidele saab linkida lisaatribuute ka mudelitest (joonistest) väljapool.

Allpool on esitatud CIA-DD atribuutide nimekiri, mida kasutatakse järgnevates näidetes. Oluline on järgida, et mistahes tarkvaras oleksid kasutusel sama struktuuriga atribuudid, seeläbi saame mistahes lähtetarkvarast eksporditavast infost ka ühtmoodi aru. Pane tähele, et osad atribuudid on kasutusel vaid kindlat tüüpi elementide juures, mille kohta leiad juba lisainfot tarkvarade näidetest.

Atribuudi nimetus	Atribuudi üldine kirjeldus
AN010_Nimetus	üldine nimetus, varaelemendi tüübi nimetus (nt Hingedega uks)
AN112_TüüpKood	esitab varaelemendi tüübi koodi (nt QQC10)
AN114_ID	esitab tüübiga seotud ID (nt QQC10_01 – ehk siis hingedega uks paigutuses 01)
AN130_SüsteemNimetus	esitab süsteemi kirjelduse/nimetuse (nt Seinasüsteemi maapealne osa)
AN132_SüsteemKood	esitab süsteemi koodi (nt B12)
AN134_SüsteemID	esitab süsteemiga seotud ID (nt B1201 – erinevalt uksest, kirjutame kompaktsuse huvides ID väärtuse kohe tüübi numbri järele aga soovi korral võib seda samuti eristada näiteks alakriipsuga)
AN160_OsasüsteemNimetus	esitab osasüsteemi kirjelduse/nimetuse (nt Homogeense keskosaga krohvitav fassaad)
AN162_OsasüsteemKood	esitab osasüsteemi koodi (nt AD12)
AN164_OsasüsteemID	esitab osasüsteemiga seotud ID (nt AD1201 – erinevalt uksest, kirjutame kompaktsuse huvides ID väärtuse kohe tüübi numbri järele aga soovi korral võib seda samuti eristada näiteks alakriipsuga)

Märkus. Atribuutide nimes olevat tekstilist osa kirjutame üldjuhul kompaktsemalt ja soovitavalt ilma tühikuteta või mistahes muude kirjavahemärkideta (sh vältida veel üht alakriipsu või sidekriipsu – nn CamelCase). Selle tekstilise osa peamine eesmärk on muuta unikaalne kood ka inimloetavaks, kuid tähe-numbriline osa on sellest siiski olulisema tähtsusega, sest sellega teostatakse hilisemaid integreerimisi/väljavõtteid. On selge, et ka eelnevalt esitatud kirjeid saaks kirjutada lühemalt, kuid siinses näites on ennekõike lähtutud nende loetavusest!

Mõned atribuudid on kombinatsioon eelnevatest atribuutide väärtustest, mistõttu need on esitatud eraldiseisva tabelina. Pane tähele, et nende atribuutide juures kasutatakse nii eelnevalt kirjeldatud atribuutide väärtuseid + lisasümboleid. Seega ongi oluline, et alusomaduse väärtus oleks n-ö puhtana saadaval, mis võimaldab sellega toimetada mistahes viisil (vastavalt tellijapõhisele infosisunõudele näiteks).

Atribuudi nimetus	Atribuudi üldine kirjeldus
AR360_UnikaalneID	viitetunnusülem, kahe või enama objektiga seotud viitetunnuste kogum, millest vähemalt üks identifitseerib üheselt selle objekti (nt soovides markeerida ukse (ehituskomponent) paigutust kindlas seinas (tehniline süsteem), mis kuulub seinasüsteemi maapealsesse süsteemi (funktsionaalne süsteem), saame selle kirjutada: B1201.AD1201.QQC10_01

Näidetesse on kaasatud ka atribuudid, mis aitavad koondada materjalipõhist informatsiooni või siis korraldada mahtude väljavõtteid.

Atribuudi nimetus	Atribuudi üldine kirjeldus
PU280_MaterjalTüüp	peamine materjali tüüp/kategooria/rühm/klass (nt puit, betoon jmt)
VP198_Ühik	mõõtmissuurus (nt tk, m, jm, m2, m3)
VP199_Maht	mõõtmise tulemus (arvuline väärtus, ühikuta)

Omaduste kombineerimisel kasutatakse EN IEC/ISO 81346 standardiseerias määratletud eraldusmärke, mis on konkreetse tähendusega ja aitavad seeläbi lihtsamini orienteeruda.

Tähemärk/sümbol	Kirjeldus
.	(punkt) üldjuhul kasutatakse kahe erineva koodi eraldusmärgina, mis üksikuna viitavad erinevatele tabelitele, kas siis lihtsalt tähekoodina, koos tüübi numbriga või ID tunnusena – nt B.AD – siin eristatakse funktsionaalse süsteemi koodi (B) tehnilise süsteemi koodist (AD) just punktiga
=	(võrdusmärk) kui seotud objekti funktsiooniaspektiga (nt seinasüsteemi saab viidata kui =B )
–	(miinus) kui seotud objekti tooteaspektiga (ehituselement)
+	(pluss) kui seotud objekti peremeespaigaldisaspektiga (nt koosolekuruum +BAB)
++	(2x pluss) kui seotud objekti paigalduskohapõhise aspektiga (nt kui diivan asub koosolekuruumis BAB, siis lisame ruumiviite kui: ++BAB)
%	(protsent) kui seotud objekti tüübiaspektiga (nt kindlale akna tüübile viitame kui %QQA10)
#	(trellid) kui seotud objekti muude aspektidega
< >	kasutatakse kui soovitakse viidata kindlale tabelile/klassifikaatorile, kust sellele järgnev kood pärineb. Näiteks RDS/CCI tabelites tähistab <CO> komponentide tabelit, <CS> tähistab ehitatud ruumide tabelit. Märkus. Alternatiivina saab kasutada ka IEC/ISO tähekoode (vt allpool).
/	(kaldkriips) kasutatakse juhul kui soovitakse ühel andmeväljal markeerida/viidata kahele erinevale kuuluvusele (viitetunnusele) – näiteks <CO>QQA /+<CS>BAA1001 tähendab, et me räägime aknast (QQA), mis on ruumis BAA1001 (ruumi viide kui <CS>), kaldkriips eristab kahte erinevat viitetunnust ning + tähistab, et me räägime kuuluvusest teisele elemendile
_	(alakriips) kasutatakse täiendava tähemärgina kui soovitakse tüüpi ning ID väärtust kompaktsemalt üksteisest eristada, parandades sellega loetavust ning võimaldades vajadusel ka ID väärtuse juures kasutada 2 numbri asemel näiteks 3 numbrikohta.

Väga oluline on vahet teha atribuudi poolt esitaval väärtusel ja seda väärtust kasutaval lisatähisel (tähemärgil). Need on erinevad asjad! Ja kuniks väärtus on omaette atribuut, siis saab sellega teha “mida iganes”, teisisõnu, vastavalt infosisunõuetele markeerida seda ühe või teise viitetunnusega (tähemärgiga).

Seega, kui lisan plaanile sildi koodiga QQA, siis ei pruugi see kasutajale öelda mitte-kui-midagi, samas kui ma lisan selle ette lisamärgituse (viite): <CO>QQA, siis määran üheselt, et tegemist on aknaga, sest sellist koodi kasutab just nimelt aken kui seda vaadata komponentide <CO> tabelist. Samas ei soovi ma seda <CO> lisaväärtust markeerida otse QQA omaduse juurde, sest see teeb keeruliseks QQA väärtuse taaskasutuse mõnes teises situatsioonis (nt unikaalse ID loomisel vmt).

Edasistes näidetes kasutame vajadusel ISO 81346-12 ühetähelisi koode.

Lisaks eeltoodule võivad olla kaasatud ka muud infosisu esitavad atribuudid aga jällegi CIA-DD koodi kasutades. Mõned näited leitavad ka tarkvarade näidetes/mallides. Infosisu kaasamisel tasub arvesse võtta, kas selle olemasolu on ehitusinfo mudelis vajalik/oluline või on mõistlik see informatsioon kaasata mõnes teises infosüsteemis. Sellest lähtuvalt on kaasatud mallides jäetud infosisu ulatus minimaalseks. Muidugi tuleb siin alati mängu tellija/projektis osalise kontekst, millist infosisu vajatakse!

Järgnevates alalõikudes käsitleme juba konkreetsemaid näiteid, milles on eelnevaid põhimõtteid rakendatud. Ehkki tarkvarade näited on piiratud, saab nendes kasutatud põhimõtteid rakendadada mistahes tarkvarale, mida konkreetne kasutaja eelistab. Tehnilisemas osas (mis järgneb üldisematele näidetele) vaatame aga lähemalt, kuidas tarkvarade mallid on üles ehitatud ja kuidas konkreetsetes tarkvarades klassifitseerimissüsteemi kasutusele võtta.