Oplæg vedr. egenskabsdata

Transkript

1 22. maj 2012 Oplæg vedr. egenskabsdata cuneco projektnummer: Metode og struktur for egenskabsdata FORELØBIG UDGAVE TIL OFFENTLIG HØRING

2 cuneco.dk center for produktivitet i byggeriet Oplæg vedr. egenskabsdata Projektgruppe Niels Treldal, Rambøll Danmark A/S Michael Blom Søefeldt, ALECTIA A/S Bent Dalgaard Larsen, Dalux Gunnar Friborg, bips Jonas Lindhardt, cuneco Søren Spile, cuneco cuneco en del af bips bips Lautrupvang 1 B 2750 Ballerup Telefon Fax bips@bips.dk Grafisk tilrettelæggelse Fænø Design 2

3 1 Indhold 1 Indhold Indledning Motivation, formål og målgruppe Metodeafsnit og tilgang Afgrænsning Generelt om objekter og egenskaber Objekter, egenskaber, objektklasser, objekt typer, objekt forekomster og objekt individer Objekter, objektklasser og egenskaber Objekter Objekttyper, objektforekomster og objektindivider Egenskaber Data og egenskabsdata Egenskabsdata og metadata Objekter og egenskaber i en bygningsmodel Egenskaber og klassifikation Egenskaber skal kunne definere typer Klassifikation skal kunne findes som egenskab Egenskaber skal være defineret i en struktur Muligheder med en klassifikation af egenskabsdata Valg af klassifikationsløsning Forslag til klassifikationsløsning Begreber for bygningsdele Fælles platform Navne skal være entydige Man skal kunne oprette egenskabsdata der mangler Metadata for egenskaber Status på objekter

4 9 Informationsniveauer Kommunikation med software Unik reference til egenskabsdata Oprettelse af database Relationer mellem objekter Arbejde internationalt Engelsk sprog Kompatibilitet med internationale standarder Sammenfatning Det videre arbejde Grundlag for struktur af egenskabsdata Identificering af egenskabsdata International koordinering Udrulning af database Bilag

5 2 Indledning cuneco center for produktivitet i byggeriet er et udviklingsprojekt, der frem til 2014 udvikler, afprøver og implementerer fælles standarder for udveksling af digitale informationer gennem alle byggeriets processer fra idéfase og projektering over udførelse til drift og vedligehold. Målet er at skabe et fælles sprog, for udveksling af informationer, som øger produktiviteten for alle aktører i byggebranchen. Et af indsatsområderne er standardisering af de informationer i form af egenskabsdata, der er tilknyttet et byggeobjekt i en bygningsinformationsmodel. Egenskabsdata er data om egenskaber dvs. en repræsentation af egenskaber på et givet objekt (DBK 2006). Egenskaber defineres som karakteristisk særpræg (DS/EN ISO 900:2000) og kan både være generelle egenskaber, der forefindes på flere objekter, eller objektspecifikke egenskaber der kun forefindes på et givent objekt. Vi anlægger i denne sammenhæng den betragtning, at egenskaber altid skal ses i sammenhæng med den objektklasse, som egenskaberne vedrører. I forbindelse med digitaliseringen af byggeriet er der behov for, at kunne udveksle egenskabsdata mellem parter ved brug af IT-systemer, hvorfor der er behov for at fastlægge en struktur for egenskabsdata, herunder en standard for den digitale udveksling. 5

6 3 Motivation, formål og målgruppe Rationalet i cunecos arbejde er, at produktivitetsmæssige mål opnås ved at facilitere veldefinerede processer ved at sørge for, at målrettet standardiseret og digital information stilles til rådighed for processerne. Struktureringen og fastlæggelsen af anvendelsen af egenskabsdata skal bruges til at beskrive hvilke informationer, der skal være til rådighed for en specifik aktør i forbindelse med en konkret proces. Dette gøres ved at beskrive hvilke objekter, der er behov for samt hvilke egenskabsdata, der skal forefindes på disse objekter. Arbejdet i indeværende projekt tager sigte på, at beskrive hvordan egenskaber skal struktureres og navngives, for at det er muligt at udveksle dem mellem parterne i forbindelse med programmering, projektering, udførelse og drift af byggeri og anlæg. Formålet med denne rapport er at redegøre for de principper, der skal danne grundlag for det videre arbejde med egenskabsdata i cunecos projekter. Dette omfatter hvordan egenskaber navngives, hvordan de struktureres og anvendes, samt hvordan aktørerne i branchen får adgang til at læse eksisterende egenskaber og komme med forslag til nye. En del af dette projekt vil også være, at definere hvilke egenskaber projektet omhandler og afklare grænseflader til klassifikation samt at udstikke retningslinjerne for efterfølgende arbejder. En meget væsentlig del af dette projekt er at beskrive opbygningen, administrationen og anvendelsen af en web-baseret database, som brugere og it-leverandører i branchen kan bruge til at tilgå fælles definerede egenskaber samt til at komme med forslag til nye egenskaber. 6

7 Denne rapport er ikke målrettet de aktører i branchen, der i sidste ende skal anvende egenskabsdata i deres arbejde men i stedet de projektdeltagere, der skal arbejde i de efterfølgende cuneco projekter, der vil være målrettet definitionen af egenskaber i forbindelse med resultater, processer og ressourcer. 7

8 4 Metodeafsnit og tilgang Som en del af projektopgaven har projektgruppen læst og forholdt sig til national og international empiri og teori i relation til egenskaber og egenskabsdata, med fokus på strukturer, metoder og tendenser og erfaringer der er indenfor området. De løsningsforslag som dette baggrundsmateriale indeholder (bla. omniclass, forvaltningsklassifikation, DBK tabel 80, SPie), sammenholdt med de praktiske erfaringer som projektdeltagerne har gennem deres daglige virke, ligger gennemgående til grund for de overvejelser og løsningsforslag som nærværende rapport peger på. Hele baggrundsmaterialet fremgår af litteraturlisten. Derudover har projektgruppen udarbejdet en præsentation, der ligger som bilag (bilag A) til denne rapport. Denne præsentation indeholder en opsummering af projektgruppens konklusioner fra gennemgangen af baggrundsmaterialet. For at undersøge status, udbredelse og forventet fremtidig udvikling af henholdsvis IFD og IFC internationalt har projektgruppen afholdt workshops med hhv. Hårvard Bell fra Catenda og Nicolas Nisbet fra AEC3, der begge er nøglepersoner i udviklingsarbejdet omkring buildingsmart. På disse workshops har de hver især redegjort for de erfaringer der er internationalt på nuværende tidspunkt og hvordan udbredelsen af IFC og IFD er tænkt fremover. På begge workshops blev projektgruppens tanker og perspektiver omkring håndtering af egenskaber og egenskabsdata fremlagt og diskuteret i relation til sammenhæng med IFD og IFC. Dette er indarbejdet i den struktur og de løsningsforslag som denne rapport foreslår. I regi af cuneco har der parallelt med dette projekt kørt et behovsanalyseprojekt, som har til hensigt at afklare hvilke indsatsområder og digitale standarder, den samlede branche peger på. En af hovedkonklusionerne er, at man som branche gennem veldefinerede informationsniveauer ønsker en forbedret mulighed for dataudveksling på tværs af hele værdikæden lige fra bygherre og bygherrerådgiver, arkitekt og ingeniører over entreprenører og underentreprenører, materialeproducenter, leverandører til driftsherrer og slutbrugere. Dette understreger det stigende behov for veldefinerede egenskaber og egenskabssæt, som gør det muligt gennem IT-værktøjer at udveksle og entydigt forstå digitale informationer. Som bilag (bilag B) til denne rapport ligger scenarier, der beskriver eksempler på situationer, hvor veldefinerede egenskaber er en nødvendighed for entydig digital udveksling mellem parterne i en given proces, hvor egenskaber ikke er målet, men midlet for at kunne opnå den optimale digitale informationsudveksling. 8

9 5 Afgrænsning Både fysiske og tænkte objekter kan have et nærmest uendeligt antal egenskaber. Det er ikke målsætningen at identificere alle tænkelige egenskaber, men derimod at etablere en struktur samt rammerne for anvendelse af egenskabsdata, således at efterfølgende identificerede egenskabsdata kan indpasses uden at struktur og rammer skal justeres. Projektet fokuserer på egenskaber, der er tilknyttet objekter i en bygningsmodel eller fastlagt som objekter i en informationsdatabase, og som definerer forskellige karakteristika på objektet. Disse egenskaber kan være parametriske værdier som bestemmer fysisk størrelse, materiale definitioner og karakteristika (fx træ, beton eller metal), leverandør data, standarder og normer, og projekt identifikationsnumre. Egenskaberne kan også indeholde/være supplerende informationer, som ikke er vist grafisk i bygningsmodellen (fx isolering omkring et rør eller tilbehør til en dør). Disse kan fx være nævnt i en bygningsdelsbeskrivelse eller et kalkulationsværktøj. Det er ikke projektets hensigt at definere egenskabsnavne og -værdier for de parametre som værktøjerne anvender internt for fx at definere geometrier eller opbygningen af dataobjekter. 9

10 Dette projekt angiver rammerne for en strukturering og anvendelse af egenskabsdata og fokus er primært de egenskaber, som udveksles mellem aktører ved programmering, projektering, udførelse og drift af byggeri og anlæg. En mere detaljeret fastlæggelse af hvilke egenskabsdata der udveksles mellem aktører, vil blive afklaret i efterfølgende projekter. 10

11 6 Generelt om objekter og egenskaber 6.1 Objekter, egenskaber, objektklasser, objekt typer, objekt forekomster og objekt individer Objekter, objektklasser og egenskaber Vi bruger to objektbegreber om genstande for vores interesse: Klasser (af objekter) og egenskaber (attributter). Ved klasser ved man altid hvilket objekt, der repræsenteres. Et klassebegreb peger på et objekt som en helhed (dvs. inkl. en række af dets egenskaber). Egenskaber anvendes for specifikation af noget og egenskaben peger ikke altid på et bestemt objekt. Egenskabsbegreber repræsenterer karakteristika ved et eller flere objekter. 6.2 Objekter Et objekt defineres som: Enhver del af verden, man kan opfatte eller forestille sig (efter ISO ). Et byggeobjekt defineres som: Enhver del af interesse inden for byggeri og anlæg (efter ISO ). Et byggeobjekt kan være fysisk som en monteret bygningsdel eller et færdigt rum, eller abstrakt som en oplevet egenskab (fx skønhed) eller et påtænkt rum. Byggeobjekter adskilles og klassificeres på basis af deres fælles karakteristiske egenskaber (som fastlægges i en formålsbestemt definition). Et byggeobjekt kan fx være bebyggelse, bygning, rum, bygningsdel, byggeproces, byggemateriale, aktør, byggemateriel etc. Hver af disse udgør en objektklasse. Klassen bygningsdele indeholder således typer af byggeobjekter, som er karakteriseret via definitionen: En del af en bygning som, i sig selv eller i kombination med andre lignende dele, opfylder en karakteristisk funktion i bygningen (efter ISO ). Et ventilationsaggregat, et belysningsarmatur, en væg, et vindue og en dør tilhører alle objektklassen bygningsdele og er adskilt og klassificeret ved deres karakteristiske egenskaber. Fx er vindue defineret som: Bygningsdel der giver mulighed for indkig, udkig og lysindfald og indgår i vinduesparti (DBK 2006). 11

12 6.3 Objekttyper, objektforekomster og objektindivider Ethvert objekt kan ses som henholdsvis type, forekomst og individ: En objekttype defineres som: Klasse af objekter der har de samme karakteristiske egenskaber (efter FDIS for IEC ). Afhængig af antallet af fælles egenskaber kan en objekttype være fra generisk til meget specifik (jf. IEC Requirements for identification systems enabling unambiguous information interchange Part 1: Principles and methods). En objektforekomst defineres som: Anvendelsen af en objekttype inden for en specifik sammenhæng(fx i et andet objekt (anlæg) eller et system (bygning)) uafhængigt af hvilket objekt individ der anvendes (efter FDIS for IEC ). Et objektindivid defineres som: Et eksemplar af en objekttype uafhængigt af, hvor den er benyttet (efter FDIS for IEC ). 6.4 Egenskaber En egenskab defineres som: Karakteristisk særpræg (DS/EN ISO 9000:2000). Byggeobjekter som ressourcer, processer og resultater har alle egenskaber (jf. begrebsmodellen i ISO se ill. nedenfor), og der kan tilknyttes egenskaber til alle objekter, der anvendes i byggeriet i forbindelse med: de ressourcer der anvendes, fx mandskab, byggevarer, byggeinformation og materiel de processer der finder sted, fx programmerings-, projekterings-, udførelses- og driftsaktiviteter de resultater der skabes, fx bebyggelser, bygninger, bygningsdele og rum. 12

13 Eksempler på egenskaber kan være: vedtagen karakteristik og typologisering fx mangel-svigt-skade, sikkerhedsklasse 1, klassicistisk, kvalitetsparametre fx god-bedre-bedst, klasse 2, identifikation fx CCS-kode, lagkode, kapitelnummer, objektbeskrivelse, adresse, lokalisering målbare enheder fx længde, bredde, højde, areal, volumen, tolerance, tidsbetegnelse oplevede kvaliteter fx smuk, grim, organisk, ubehagelig, tillidsvækkende, kompleks, fritliggende, større, mindre mfl. Egenskaber er således helt centrale informationer der skabes, søges, udveksles og anvendes af alle byggeriets aktører. 6.5 Data og egenskabsdata Data anses som regel for at være det første og mindste led i kæden: data, information, viden. I denne rapport anvendes begrebet data om information der skabes, udveksles og anvendes digitalt. Egenskabsdata er således informationer om egenskaber brugt i en digital sammenhæng. Egenskabsdata er den digitale information om egenskaber ved tænkte eller fysisk eksisterende objekter. Egenskabsdata er således en digital specifikation som definerer egenskaberne ved fx en objektklasse, et objekt, en enhed eller en fil og kan også referere til en specifik værdi for en given instans, en specifik udgave af et objekt. På engelsk kaldes egenskaber og egenskabsdata attributes, properties eller metadata, afhængig af hvilke sammenhænge de indgår i. En egenskab kan findes i sig selv, fx som bredde, men den får først betydning som egenskabsdata i det øjeblik, den anvendes som information i forhold til et konkret objekt, og der er taget stilling til hvilke værdier og enheder der kan knyttes til. 13

14 For at gøre egenskabsdata operationelle i byggeriet er det vigtigt at definere hvilke objektklasser, fx vægge, der har hvilke egenskaber, og hvilke værdier og enheder der er fastlagt og kan anvendes for disse. 6.6 Egenskabsdata og metadata Metadata er en beskrivelse af andre data, dvs. data om data. Når egenskabsdata foreligger i en fastlagt form (som et dataelement) med angivelse af egenskab, definition, tilhørende værdilister eller værdier og enheder, relationer mv., kan egenskabsdata i realiteten betragtes som beskrivende metadata, dvs. metadataindhold. Metadata som begreb anvendes dog hyppigst inden for informations- og dokumenthåndtering, arkivering, biblioteker m.fl. Derfor anvendes egenskabsdatabegrebet som generelt begreb i denne rapport, selv om der kan forekomme egenskabsbegreber af informationsmæssig karakter både i rapporten og den foreslåede klassifikationsstruktur for egenskaber. 6.7 Objekter og egenskaber i en bygningsmodel En bygningsmodel indeholder objekter, som alle har tilknyttede egenskabsdata. Overordnede objekttyper i en bygningsmodel kan ses som: objekter, der repræsenterer bygningens rum (rumlige objekter) objekter, der beskriver bygningsdele (fysiske objekter) objekter, der repræsenterer begrebsmæssige enheder, eller som er sammensat af flere andre objekter (sammensatte / administrative objekter) De to førstnævnte kategorier er modelleringens virtuelle byggeklodser i bygningsmodellen, hvorimod den tredje kategori oftest repræsenterer resultatet af modellering. I en bygningsmodel er det på baggrund af objekter og deres tilhørende egenskabsdata muligt at strukturere informationer til et givent formål. Fx til simulering eller mængdeudtræk kan man via egenskaber udvælge og sortere relevant information. 14

15 7 Egenskaber og klassifikation Klassifikation er relevant i forhold til egenskaber ud fra tre forskellige perspektiver. 1. Objekter kan inddeles i klasser ud fra fælles sæt af karakteristiske egenskaber. Eksempler på dette kunne være klasserne vægge, dørpartier, vinduespartier etc. De enkelte objekter vil have en egenskab, der gennem en klassifikationskode fortæller, hvilken objektklasse de tilhører. 2. Værdilisterne for egenskaber kan være klassificerede. Dette vil fx være tilfældet når indholdet af en værdiliste er baseret på normer og/eller standarder. Eksempler på dette er brandklasser, betonstyrker, vandtæthed etc. 3. Egenskaber kan inddeles i klasser i henhold til en klassifikationsstruktur. 7.1 Egenskaber skal kunne definere typer I klassifikationssammenhæng har man behov for at kunne adskille objekter fra hinanden på baggrund af deres type. I den forbindelse er det egenskabsdata, der adskiller typerne fra hinanden. Dette kan principielt foregå efter to forskellige principper. 1. Det ene princip er, at der for alle objekter defineres typer (fx bygningsdelstyper) på basis af en overordnet karakteristisk egenskab (fx opbygning, materialeegenskab, form el.lign.). På baggrund af denne karakteristiske egenskab grupperes objekterne. En begrænsning ved denne struktur er, at den er meget ufleksibel m.h.t. inddelingskriterier, da man for hver objektklasse vil skulle definere, hvad der adskiller de enkelte typer fra hinanden, og hvilket inddelingskriterie, der er vigtigst for flest parter i byggeriet. Alternativt skal have mange (bygningsdels-)typer knyttet til objektet i henhold til mange parters specifikke behov. Det vil være stort set umuligt, at definere inddelingskriterier, der er konsistente på tværs af objektklasserne, og som alle byggeriets aktører vil kunne acceptere som værende den vigtigste type. 15

16 2. Det andet princip er at definere typeklassifikationen som rapportudtræk, hvor byggeriets parter pr. objektklasse definerer hvor mange og hvilke egenskaber, der indgår i en relevant typeklassifikation, der dækker de flestes behov og ud fra nogle overordnede fastlagte væsentlighedskriterier. Resultatet kan fx være, at man for indervægge definerer, at typer adskilles på baggrund af opbygning og materialer mens det for vinduer er funktion, form og materialer, der adskiller objekterne (illustreres med figur). Det giver derved stadig mulighed for, at man til enhver tid kan udtrække lige præcis den eller de typiske egenskaber, som kan have betydning for forskellige aktører i forskellige processer, uden at egenskaberne forekommer i en låst sammenhæng. Delkonklusion: Egenskabsdataprojektet foreslår at model 2 vælges, da det giver mulighed for at kunne fastlægge en typificering, der kan tilfredsstille flest mulige aktører og samtidig sikre størst mulig frihedsgrad med hensyn til anvendelse af egenskabsdata. De enkelte egenskabsdataværdier vil i sig selv kunne udgøre en klassifikation, fx brand- og sikkerhedsklasser for døre, lydklasser og lysgennemgang for vinduer etc. 16

17 7.2 Klassifikation skal kunne findes som egenskab Klassifikationskoden for objekter skal kunne findes som en egenskab for objektet. Da IfcClassification strukturen endnu ikke er indarbejdet i noget software, bør klassifikationskoden kobles til objekter som øvrige egenskaber. cuneco bør arbejde på at IfcClassification tilpasses den fremtidige CCS struktur og implementeres i softwaren. Den samlede klassifikationskode angives som én egenskab på objektet. Pr. objekt skal det desuden være muligt at tilknytte én alternativ klassifikationskode fx baseret på byg- eller driftsherrens eget tilpassede klassifikationssystem. 7.3 Egenskaber skal være defineret i en struktur For at gøre det nemmere at finde og identificere egenskaber, fastlægges en struktur, som egenskaberne defineres og klassificeres i overensstemmelse med, og som de kan findes igennem. Dermed bliver brugere af egenskabsdatabasen i stand til at finde en konkret egenskab ud fra viden om typen af egenskab. En sådan struktur påvirker ikke egenskabsdatabasens opbygning men vil alene være en "type-af" klassifikation, som tilknyttes hver egenskab som metadata Muligheder med en klassifikation af egenskabsdata Det vil blive et voksende problem, at det kan blive uoverskueligt med mængden af egenskaber, efterhånden som der bliver defineret og fastlagt flere og flere egenskaber. Der kan findes flere måder at løse dette problem på: 1. Egenskaberne kan sættes ind i en klassifikationsstruktur. (Samme koncept som kendes fra fx eksisterende byggeklassifikation, biblioteker, Yahoo og Jubii). Såfremt en egenskab logisk kan placeres flere steder i strukturen placeres den hvor den er vigtigst. Det kan fx være hvis en egenskab er væsentlig både for lyd og lys, så må det vurderes, hvilken der er vigtigst. 2. Egenskaber kan påsættes tags som beskriver anvendelsen af egenskaben. Hvis en egenskab både er vigtig for lys og lyd vil den så få 2 tags med lys og lyd og dermed elimineres en stillingtagen til, hvad der er vigtigst. Det vil dog give databasen ekstra kompleksitet og ikke udgøre en egentlig klassifikation. 3. Beskrivelsesfeltet for egenskaben bruges til at beskrive anvendelsesområderne for egenskaben og det vil så være muligt at søge efter egenskabernes anvendelsesområder (google metoden). 17

18 Model 3 vil nemt blive for ustruktureret og vil kræve, at man ved hvilken egenskab man præcist søger. Model 3 vil kunne anvendes som et supplement, men vil ikke give mulighed for at browse rundt i egenskabsdatabasen og lade sig inspirere af andre egenskaber som fx beskriver noget om termiske forhold. Model 1 vil gøre det muligt både at søge i databasen (som model 3) og vise databasens indhold som en samlet struktur/oversigt. Model 2 vil give mulighed for databasesøgning men vil være svær at vise som en samlet struktur. Delkonklusion: Arbejdsgruppen foreslår, at model 1 og 3 vælges, idet en klassifikationsstruktur både kan understøtte søgning i databasen og visning af den samlede struktur. Løsningen forhindrer ikke en senere udbygning med tagging af egenskaber. En sådan struktur kan derudover tjene til og understøtte: Mulighed for yderligere klassifikation ved anvendelse af karakteristika / egenskaber ved byggeobjekter Processen med at stille krav til byggeobjekter i forbindelse med beskrivelse af ydelser eller leverancer Beskrivelse af karakteristika ved en endnu uidentificeret løsning for et byggeobjekt i forbindelse med søgning eller fastlæggelse af krav Sammenligning og vurdering af egenskaber ved forskellige eller ens byggeobjekter Klassificering af information i tilknytning til byggeobjekter Facilitering af og ordning af information vedrørende byggeobjekter i dokumenter, ved display og ved lagring og søgning Valg af klassifikationsløsning Mulige strukturer kunne være strukturen fra DBK tabel 80, OmniClass tabel 49, CIB Masterlist eller Lise Borups Masterliste for egenskaber. I ISO står der om Egenskaber: Members of all the classes have properties and characteristics. I DBK 2006 står der om Egenskabsdomænet: Et område af interesse for byggeriet, som omfatter de egenskaber, som kan knyttes til ressourcer, processer og resultater. Ved et kig på OmniClass fra 2006, CIB Masterlist fra 1993, AB Svensk Byggtjänst 'Klassifikation av Byggnadsverk och Utrymmen - huvudstudie' fra 2002 samt Lise Borups 'Byggeriets egenskaber..' fra 2002 er det tydeligt, at oversigter og strukturer primært vedrører produkters egenskaber. De kan altså primært henføres til byggevarer i Ressourcedomænet og til nogle af de byggede resultater (specifikt bygningsdele) i Resultatdomænet i relation til begrebsmodellen i ISO Således er hverken Procesdomænets objekter, en lang række objekter i Ressourcedomænet eller nogle af de øvrige objektklasser i Resultatdomænet dækket ved det hidtidige strukturarbejde på egenskabsområdet. 18

19 OmniClass, tabel 49 Properties, der p.t. er under revision, er fx også afgrænset til alene at omfatte bygninger og de dele, der indgår heri: Properties are characteristics of construction entities. I cuneco-projektet omfatter strukturering, klassificering og anvendelse af egenskaber imidlertid alle tre domæner defineret i ISO Der kan være to mulige kriterier at fastlægge strukturen ud fra: 1. Enten skabes der en struktur for egenskaber, hvor egenskaber oplistes og klassificeres i forhold til de domæner og disses objektklasser, som er defineret som Ressource-, Proces- og Resultatdomænet via begrebsmodellen i ISO Eller der udarbejdes en struktur hvor egenskaber grupperes og klassificeres via deres egne karakteristiske særpræg dvs. egenskaber ved egenskaber. Model 1 vil sandsynligvis bevirke, at en række egenskaber, der kan være fælles for objekter inden for flere domæner, skal klassificeres flere steder. Det vil gøre det svært at lave en ren klassifikation og dermed også usikkert, hvor disse egenskaber skal placeres eller findes. Eksempler: Restlevetid kan både knyttes til en bygningsdel (Resultat), til livscyklus (Proces) og til et materiel (Ressource). Højde kan både knyttes til en bygningsdel (Resultat), til en maskine eller en byggevare (Ressource). Model 2 vil give den reneste klassifikation, hvor restlevetid vil blive grupperet/klassificeret under tidsegenskaber og højde under dimensionsegenskaber. Egenskaberne kan derudover tilføjes metadata (egenskaber), der fx kan angive hvilken bygningsdel, hvilke typer byggevarer, hvilke processer, hvilke aktører og hvilke overordnede domæner etc., disse egenskaber kan relateres til. Delkonklusion: Egenskabsdataprojektet foreslår at model 2 vælges, da det vil give den reneste klassifikation og bedst mulighed for at skabe relation til mange (lige vigtige) byggeobjekter, domæner etc Forslag til klassifikationsløsning Der gives i dette projekt et første bud på en sådan egenskabsstruktur se Bilag D: Foreløbigt forslag til strukturering af egenskaber. I forslaget er der foreløbig fastlagt overordnede og specifikke klasser for egenskaber, men der er endnu ikke påført klassifikationskode. De opgivne eksempler på egenskaber har heller ikke fået en klassifikationskode, da det endnu ikke er afklaret, om det vil have et formål. Der foreslås efterfølgende etableret et opfølgende projekt eller nogle mindre workshops, fx i samarbejde med Anders Ekholm og evt. Lise Borup mfl., hvor løsningsforslag diskuteres teoretisk og også prøves af. 19

20 7.4 Begreber for bygningsdele I byggeindustrien benyttes en lang række begreber for bygningsdele der konceptmæssigt ligger tæt op ad eller er relateret hinanden, fx som overbegreb og underbegreber et underbegreb kan fx være en type af. Et eksempel er Trappe som findes i mange varianter. Det kan fx være Ståltrappe, Betontrappe, Vindeltrappe osv. Der vil i forskellige sammenhænge være brug for at få listet mængder af disse. Som beskrevet i et tidligere afsnit er det valgt at disse varianter vil høre til samme objektklasse, nemlig klassen Trappe. Måden hvorpå man finder ud af hvilket begreb objektet har, vil så være ved hjælp af egenskaber. Et begreb vil også kunne dannes som en objektklasse der indeholder en kombination af flere egenskaber. Dette vil kunne beskrives således: Objektklasse Egenskabsdata Begreb Trappe Materiale= Stål Ståltrappe Trappe Materiale= Træ Trætrappe 20

21 8 Fælles platform 8.1 Navne skal være entydige For entydigt at kunne genfinde en egenskab i strukturen af egenskaber er det nødvendigt at have en unik identifikator på alle egenskaber. Da det ikke vurderes hensigtsmæssigt at anvende IFD GUID'er til entydigt at identificere egenskaber pga. den begrænsede udvikling og udbredelse af IFD, er det egenskabens engelske navn, som entydigt skal identificere egenskaben. Det bliver således egenskabens engelske navn som identificerer egenskaben. Egenskabens engelske navn skal være entydigt pr. objektklasse. Dvs. at egenskaber godt kan hedde det samme på forskellige objekter, men pr. objektklasse er de entydigt identificerbare. Egenskabsnavne skal være identiske med navne i IFC, såfremt egenskaben findes i IFC-specifikationerne. Egenskaber skal også placeres i samme IFC Property Set, som foreskrives i IFC-specifikationerne, hvis den findes. Eksisterer egenskaben ikke i IFC, skal egenskaben navngives efter principperne i IFC. Tilsvarende skal sådanne egenskaber knyttes til et IFC Property Set med samme navn som tilsvarende egenskaber ligger i, dette IFC Property Set skal dog navngives med et _DK suffix. Det skal bemærkes at projektgruppen finder at egenskabernes inddeling i IFC Property Sets ikke i alle tilfælde er hensigtsmæssig, da de anvendte IFC Property Sets i nogle tilfælde er defineret vilkårligt og uden en entydig struktur. Dette medfører bl.a. at definitionen af egenskaber i forskellige IFC Property Sets overlapper hinanden for samme objektklasse, og at entydigheden i placeringen af en given egenskab dermed mangler. Grundet den nuværende IFC implementering i værktøjerne vælges det dog ikke at ændre på defineringen af egenskaber i IFC sammenhæng. Projektgruppen løser problemet med entydig definering af egenskaber for en given objektklasse ved alene at pege på én IFC egenskab i ét givet IFC Property Set pr. objektklasse upåagtet af, at der i IFC specifikationerne kan findes flere måder at definere egenskaben på. Valg af rette IFC egenskab må bero på en vurdering af hvilken egenskab, som bedst matcher den ønskede. 8.2 Man skal kunne oprette egenskabsdata der mangler Selv om cuneco løbende vil arbejde med at definere de egenskaber, der viser sig at være behov for i forbindelse med at branchens aktører udveksler data digitalt med hinanden, vil brugerne i praksis komme ud for, at de 21

22 har behov for at anvende egenskaber, der ikke er defineret i egenskabsdatabasen. Der vil derfor være behov for, at brugerne løbende kan tilføje deres egne egenskaber og anvende disse i leverancen af data til samarbejdspartnere uden at et stort administrativt apparat skal sættes i gang. Egenskabsdatabasen kan således både indeholde egenskaber, der er godkendt af cuneco, og egenskaber, der er oprettet af de enkelte brugere. Egenskaber får metadata i cunecos database, der angiver om det er en officiel egenskab. Software vil slå op i cunecos database for at undersøge om en given egenskab er officielt defineret. Findes den pågældende metadata ikke eller har den metadata Officiel som FALSE vil det opfattes som om egenskaben ikke er defineret af cuneco. Egenskaber, der ikke er defineret af cuneco vil tillige have metadata, der angiver hvilken bruger, der har oprettet den pågældende egenskab. Da det vil være uhensigtsmæssigt, at egenskabsdatabasen bliver fyldt op med en lang række brugerdefinerede egenskaber, vil cuneco løbende følge op på de egenskaber, der bliver oprettet af brugerne, og lave en vurdering af, om disse egenskaber skal gøres til officielle egenskaber. De egenskaber, som cuneco beslutter at ophøje til officielle egenskaber vil blive overført til et område på cuneco-serveren, hvor det vil ligge i en høringsperiode, hvor det vil være muligt for brugerne af cuneco-databasen at kommentere på den pågældende egenskab. Det vil løbende blive publiceret hvilke egenskaber, der er gjort til officielle cuneco egenskaber. I mange bygge- og anlægsprojekter vil man sikkert få behov for nogle specielle egenskaber. Disse egenskaber skal det være muligt at oprette så man kan benytte dem på lige fod med officielle cuneco egenskaber. I projekter vil man så benytte en kombination af cuneco standard egenskaber og ad hoc definerede egenskaber. Såfremt disse ad hoc definerede egenskaber skal udveksles med andre og det er nogle man jævnligt får brug for, vil det være en fordel at få dem optaget som cuneco standard egenskaber. Det vil så ikke være nødvendigt at oprette og aftale disse egenskaber til hvert projekt. I forbindelse med anvendelsen af egenskaberne skal det være muligt for brugerne at angive, om egenskaben er oprettet projektspecifikt eller som en overordnet CCS-egenskab. Dette vil sikre, at det bliver operationelt at aftale anvendelse af nye egenskaber inden for enkelte projekter, uden at egenskabsdatabasen bliver fyldt op med en lang række brugerdefinerede egenskaber, der egentlig betyder det samme. 22

23 Projektspecifikke egenskaber vil være koblet til projekterne gennem et Projekt id. Projekt id er en nøgle, der refererer unikt til det pågældende projekt. Projekt id er defineret i afsnit 8.1 Metadatasæt i bips publikation F104 Dokumenthåndtering. På cuneco-serveren vil man kunne se hvilke se hvilke egenskaber, der er defineret for et givet projekt. For deltagerne i et projekt vil det være muligt at slå op i cuneco databasen for at se om en egenskab er en CCS egenskab eller en projektspecifik egenskab. Det bør også være muligt at lave udskrift af listen med egenskaber der er benyttet i et projekt. På den liste vil det så også være muligt at identificere hvilke egenskaber der er CCS egenskaber, og hvilke der er projektspecifikke egenskaber. Historik skal gemmes for alle egenskaber i databasen, så man kan følge deres udvikling fx fra forslag fra en bruger til officielt defineret CCS egenskab. Vedligehold af egenskaber vil være et af de forretningsområder, som cuneco vil tage sig betalt for. 23

24 Det nedenfor illustrerede scenarie giver et bud på, hvordan en bruger vil kunne oprette egne egenskaber og udveksle dem med samarbejdspartnere. 8.3 Metadata for egenskaber I forskellige sammenhænge i byggeriet arbejder man med forskellige enheder. Fx meter, centimeter eller millimeter. Forskellige IT systemer anvender også forskellige enheder. Programmet Autodesk Revit benytter fx altid feet internt (som dog godt kan vises som SI enheder i brugerfladen) De fleste IT-systemer definerer entydigt enheder samt andre definitioner for hver egenskab. Dvs. at det ikke er muligt vha. metadata at angive alternative enheder eller fortælle om beregningsmetoden der er anvendt til at beregne værdien på egenskaben. For at kunne skabe en sammenhæng både i udvekslingen mellem personer og mellem IT systemer er det derfor nødvendigt ikke blot at kende egenskabsnavnet, men også fx enhed og eventuelt andre metadata for egenskaben. Et forslag til en notation der kunne anvendes er: {property}.{description} Dog understøttes denne notation eller andre notationer med samme funktion ikke i de IT-systemer, der p.t. anvendes i byggeindustrien. Der findes dog måder hvormed man alligevel kan arbejde med egenskaberne på tværs af IT-systemer. 24

25 Hvis forskellen på egenskaber i 2 IT-systemer skyldes forskellige størrelser såsom meter, centimeter, millimeter eller forskellige enheder såsom feet og meter kan dette løses vha. standardoversættelser defineret i et andet IT-program eller en generelt tilgængelig database med disse informationer på cuneco serveren. Hvis det derimod er vigtigt at fortælle hvilken beregningsmetode der er benyttet for en egenskab kan man benytte en notation som fx: {property}.{calculationmethod} Da ingen eller meget få systemer understøtter dette, så vil man i praksis oprette en ny egenskab med navnet: property_calculationmethod. Dette vil samtidig have den effekt, at man ikke risikerer at systemer fejlfortolker egenskaber fordi de ikke er opmærksomme på, at der forekommer metadata, der angiver at egenskaben afviger fra det, der er defineret som standard. På cuneco serveren defineres det sådan at alle egenskaber får en standard enhed, der anvendes hvis andet ikke er angivet. Initielt bruges denne enhed altid, men systemet laves åbent i forhold til, at egenskaben kan have metadata, der fx angiver hvilken enhed der anvendes På cuneco serveren vil det således være muligt at relatere cuneco egenskaber til forskellige IT-systemer med forskellige metadata på en egenskab. Fx kan et system benytte feet som længde enhed, mens et andet benytter millimeter. Cuneco serveren bør derfor understøtte notationen: {property}.{description} og så oversætte til mere primitive former afhængig af hvilket IT system, der laves integration til. På sigt vil det være hensigtsmæssigt at denne metodik tages op internationalt med henblik på at få implementeret understøttelse af dette i ITsystemerne. 8.4 Status på objekter Formål: Det kan være hensigtsmæssigt at kunne definere om et givet objekt er gældende eller ikke-gældende sådan at fx en bygningsmodel kan fremsendes i sin helhed også selvom dele af modellen ikke er færdig og derfor ikke ønskes angivet som værende gældende. 25

26 Det foreslås at anvende en egenskab for alle objekter som hedder "Status". Egenskabens værdier følger bips F104 for værdilisten for Status, herunder "Uden udarbejdelse", "Udgivet" mv. For at sikre fx bygherren mod at et projekt er uoverskueligt ved en faseaflevering, bør det ikke være tilladt at angive anden status end "Udgivet" for objekter, som afleveres ved en faseaflevering. Egenskaben "Status" kan således alene anvendes i løbet af en fase i forbindelse med fx løbende udveksling mellem to parter. 26

27 9 Informationsniveauer Et centralt formål med egenskabsdata er at skabe grundlaget for at kunne definere informationsniveauer med udgangspunkt i egenskaber for objekter i en bygningsmodel. Dette vil blive nærmere defineret i forbindelse med cunecos projekt for informationsniveauer. Det forudsætter dog, at de nødvendige egenskaber er defineret eller at det er muligt og operationelt at oprette egenskaber efterhånden som behovet for dem opstår. For at informationsniveauer skal kunne anvendes på strømlinet og fleksibel vis i en digital sammenhæng, skal det være muligt for IT-systemer, at hente egenskaber i strukturerede digitale formater som bygningsmodeller, beskrivelsessoftware, producentdatabaser m.v., hvilket forudsætter at egenskaber er entydigt definerede. 27

28 Informationsniveau Informationsniveau Informationsniveauet for aflevering af data til energiberegning angiver at en væg inkl. egenskabsdata for U-værdi skal overføres fra et BIM-værktøj til et energiberegningsprogram. Internt i BIM-værktøjet hedder væggen og Wall og U-værdien U-value. I energiberegningsprogrammet hedder væggen VAEG og U-værdien U-VAERDI. IT-system1 Wall U-Value cuneco DC Væg {egenskabsnavn} cuneco DC Væg {egenskabsnavn} IT-system2 VAEG U-VAERDI Eksemplet illustrerer at definitionen af et informationsniveau beskriver, at der i forbindelse med en given beregning skal udveksles informationer omkring et objekt af objektklassen Væg, og at disse informationer skal omfatte egenskaben U-værdi. I forbindelse med denne udveksling ligger der en udfordring i, at objektet Væg og egenskaben U-værdi hedder noget forskelligt i de to værktøjer, der skal udveksle informationerne. Løsningen fra cunecos side består i, at cuneco definerer dels objektklassifikation og dels egenskabsdatanavngivning og -indhold, der gør det muligt for begge systemer at referere til de samme CCS begreber og dermed få lavet en indbyrdes oversættelse af betegnelserne. Når der udveksles digitale modeller mellem flere parter er der en meget væsentlig problematik, der består i, at modtageren af modellen ikke kan være sikker på, hvor meget af informationen i modellen, der er gældende for den opgave, som han skal udføre. En model vil ofte indeholde en stor mængde information i form af egenskaber, der kun er foreløbige, og som der således ikke er taget stilling til endnu. Når en model eller et udtræk fra en model ovedrages fra en part til en anden, vil der være aftalt et informationsniveau for leverancen, og det er dette informationsniveau, der fortæller modtageren, hvilke egenskabsdata han kan basere sit arbejde på. 28

29 10 Kommunikation med software 10.1 Unik reference til egenskabsdata For at egenskabsdata er tilgængelige fra IT-systemer, skal det være muligt unikt at udpege en egenskab på baggrund af en kode eller et navn for egenskaben. De fleste IT-systemer opererer med en lang række egenskaber, der er defineret internt i systemerne. Koblingen mellem disse interne egenskaber og cunecos egenskabsdata vil være defineret i tabeller, der mapper en intern egenskab til den tilsvarende cuneco egenskab. Ved at cunecos egenskaber navngives med betegnelserne fra IFC vil man i nogle sammenhænge kunne opnå, at IT-systemerne vil kunne aflevere disse egenskaber med de rigtige navne i den udstrækning, de konkrete egenskaber er defineret i IFC Oprettelse af database Samarbejdet omkring cunecos arbejde med egenskabsdata vil i høj grad komme til at være centreret om en web-baseret databaseplatform, hvor alle interessenter vil have mulighed for at se de definerede og godkendte egenskaber. Det vil også være muligt på projektbasis at oprette egne egenskaber samt at komme med forslag til nye egenskaber, der efterfølgende vil blive evalueret for godkendelse som officielle egenskaber. I nedenstående figur ses forslaget til hvordan egenskabsdatabasen kan se ud. 29

30 Tilgangen til databasen vil ske vha. en web applikation. Nedenstående viser hvordan et skærmbillede i denne applikation kan se ud Relationer mellem objekter Når objekterne befinder sig i en bygningsmodel, er der en række logiske relationer mellem objekterne. Nogle kan fremgå af modellen. F.eks. et vindue vil fx sidde i en væg og befinde sig i et rum. Der er også relationer som kan være mere skjulte. F.eks. hvilket ventilationsanlæg der leverer luft til et rum. Disse relationer vil i forskellige sammenhænge være interessante at kunne finde frem til. Som eksempel vil det ved en energiberegning være interessant at vide, hvilken væg vinduet sidder i (fx til at finde ud af hvilke type kuldebro der opstår), mens det i drift- og vedligeholds-sammenhænge kan være interessant at vide, hvilket rum vinduet sidder i. Disse relationer kan beskrives vha. egenskaber. I eksemplet med vinduet vil det kunne beskrives som følgende vha. egenskaber: Egenskaber for vindue (Window1) Egenskab PartOf RelationTo Egenskaber for væg (Wall1) Egenskab SubParts Værdi Wall1 Room1 Værdi Window1, Window2 30

31 RelationTo Egenskaber for rum (Room1) Egenskab SubParts RelationTo Værdi Window1 Denne form for relationer vil især være nødvendig for at beskrive sammenhænge i anlæg. Fx når det skal beskrives, hvilket anlæg en pumpe leverer til, eller fra hvilken el-tavle et anlæg trækker strøm fra. Egenskaber af denne type vil være vigtige i en konkret bygning. cuneco serveren vil dog ikke indeholde denne type egenskaber. Det eneste, der skal fastlægges fra cuneco, er hvilke mulige relationer, det vil være interessant at beskrive vha. denne type egenskaber, samt hvad egenskabsnavnene på disse skal være. I ovenstående eksempel er egenskaberne PartOf, RelationTo og SubParts benyttet. Om disse er passende og dækkende for alle typer relationer mellem bygningsdelsobjekter er det op til efterfølgende projekter at afgøre. 31

32 11 Arbejde internationalt 11.1 Engelsk sprog For at understøtte internationaliseringen skal navne på egenskaber være engelsksprogede ligesom definitioner for egenskaber skal foreligge på engelsk. Som supplement angives der dansksprogede alias for navne og dansksprogede definitioner. Det vil være de engelsksprogede navne på egenskaberne, der refereres til fra IT-systemernes side. Der skal fastlægges en fremgangsmåde for håndtering af tilfælde, hvor cuneco ikke er enige i betegnelser, der fx anvendes i IFC sammenhæng Kompatibilitet med internationale standarder Kompatibilitet med de arbejder, der finder sted i buildingsmart regi sikres ved at anvende navngivningsprincipper, der er kompatible med buildings- MART Datamodel og buildingsmart Dictionaries, som det er beskrevet i afsnittet ovenfor. Dette vil sikre, at egenskabsarbejdet i cuneco er kompatibelt med det arbejde vedr. egenskaber, der finder sted i forbindelse med bl.a. COBie og SPie. I buildingsmart regi arbejdes der på at sikre at danske egenskabsdefinitioner er konsistente med internationale definitioner ved at der i et buildingsmart projekt laves dansksprogede definitioner af egenskaber i IFC Property Sets. Grundlaget for koblingen til begrebsdefinitioner sikres endvidere ved at der laves plads til at lægge referencer til buildingsmart Dictionary (IFD) ind i cunecos egenskabsdatabase i form af IFD GUID s. Dette arbejde iværksættes ikke umiddelbart men vil afvente en større udbredelse og anvendelse af IFD i branchen. Endelig vil navngivningen af cuneco egenskaber følge principperne fra IFC Properties og IFC Property Sets, som det er beskrevet i afsnit 8.1 Navne skal være entydige i denne rapport. Egenskaber vil være navngivet i overensstemmelse med retningslinjerne ved navngivning af IFC Properties. Dette betyder at egenskaberne vil få engelsksprogede navne. Navnene skrives i ét ord uden mellemrum, understregninger eller bindestreger. Navnene vil typisk være sammensat af flere 32

33 ord og hvert ord starter med et stort bogstav og skrives efterfølgende med små bogstaver. Eksempler på navne på IFC Properties er: IsExternal LoadBearing AcousticRating Combustible Navnet på et IfcPropertySet, der er defineret i buildingsmart-regi begynder med Pset_ efterfulgt af en beskrivelse på engelsk af, hvad det pågældende IfcPropertySet vedrører. IfcPropertySets der defineres i cuneco regi vil være navngivet på tilsvarende vis men vil have et _DK tilføjet i slutningen af navnet. Brugerdefinerede IfcPropertySets må ikke begynde med teksten PSet_. Definitionerne af objekt type og objekt forekomst er helt analoge med de definitioner af Type og Occurrence, som der anvendes i IFC-verdenen jævnfør figuren ovenfor. Udfaldsrummet for gyldige værdier for specifikke egenskaber vil i vid udstrækning være defineret af internationale standarder. I bips regi arbejdes der p.t. på en referencedatabase, der kan bruges til at holde styr på hvilke versioner af standarder m.v., der er gældende på et givet tidspunkt. cunecos egenskabsdatabase vil have en kobling til denne referencedatabase, for at sikre at man kan styre hvilken version af en værdiliste for en egenskab, der anvendes i et specifikt projekt. Dette vil skulle understøttes af, at der er tilknyttet historik på de enkelte egenskaber i cuneco databasen. 33

34 12 Sammenfatning Det har været dette projekts formål at skabe en struktur for, hvordan egenskabsdata håndteres og udveksles, så det er muligt for både mennesker og it-systemer at aflæse og tolke egenskaberne entydigt. Projektgruppen har analyseret løsningsmuligheder på baggrund af omfattende national og international teori og empiri og workshops med nøglepersoner på området fra udviklingsarbejdet i buildingsmart. Herudfra har projektgruppen foreslået en række løsninger til håndtering af egenskabsdata, som sammenfattes i det følgende. Entydig navngivning: Egenskabers navne skal være entydige for at it-systemer og mennesker kan genfinde dem. Egenskabsnavne skal være på engelsk og skal være identiske med navne i IFC. Eksisterer egenskaben ikke i IFC, skal egenskaben navngives efter principperne i IFC. Egenskaber skal placeres i det IFC Property Set, som foreskrives i IFC-specifikationerne, hvis den findes. Egenskaber skal være defineret i en struktur: Egenskaberne skal grupperes i en struktur. Der skal udarbejdes en struktur for gruppering og klassificering af egenskaber via deres egne karakteristiske særpræg dvs. egenskaber for egenskaber. Det skal være muligt at lave fritekstsøgning på egenskaber. Der skal være sammenhæng mellem egenskaber og informationsniveauer: Informationsniveauer angiver hvilke egenskabsdata der er til rådighed på et konkret tidspunkt. Dette forudsætter en entydig navngivning og definition af indhold af egenskaber. Informationsniveauer vil gøre det være muligt at styre hvilke egenskaber der på et konkret tidspunkt i processen er gældende. Der skal være sammenhæng mellem egenskaber og klassifikation Egenskaber skal kunne definere typer Klassifikationskoden for objekter skal kunne findes som en egenskab for objektet. Metadata for egenskaber: Informationer om enhed, referencestandard, beskrivelse m.v. skal kunne defineres i form af metadata for en egenskab. Metadata for egenskaber får standardværdier, der anvendes hvis andet ikke er angivet. Initialt bruges disse værdier altid, men sy- 34

35 stemet laves åbent i forhold til, at egenskaben kan have metadata, der fx angiver hvilken enhed der anvendes. Det foreslås at anvende en egenskab for alle objekter som hedder "Status". Egenskabens værdier følger bips F104 for værdilisten for Status, herunder "Uden udarbejdelse", "Udgivet" mv. Kommunikation med software Egenskabsdata bliver tilgængelige på en web-baseret databaseplatform, hvor alle interessenter kan se de definerede og godkendte egenskaber. Det skal også være muligt at oprette projektspecifikke egenskaber samt at komme med forslag til nye egenskaber, der efterfølgende vil blive evalueret for godkendelse som CCS egenskaber. For at egenskabsdata er tilgængelige fra it-systemer, skal det være muligt unikt at udpege en egenskab på baggrund af en kode eller et navn for egenskaben. Internationalt kompatibelt Navne på egenskaber være engelsksprogede. Som supplement angives der dansksprogede synonymer for egenskabsnavne og dansksprogede definitioner. Der anvendes navngivningsprincipper, der er kompatible med buildingsmart Datamodel og buildingsmart Data Dictionaries. 35

36 13 Det videre arbejde 13.1 Grundlag for struktur af egenskabsdata I første halvdel af 2012 gennemføres et offentligt høringsforløb af nærværende projekt. På baggrund af tilbagemeldingerne fra høringen færdiggøres projektet, og den udarbejdede rapport vil ligge som grundlag for det videre arbejde med egenskabsdata blandt brugere i byggebranchen Identificering af egenskabsdata Fra og med andet kvartal af 2012 skal samtlige bips og cuneco projekter forholde sig til hvilke egenskaber, der skal anvendes indenfor for det domæne, som projekterne beskæftiger sig med. Disse egenskaber skal defineres, navngives og beskrives, hvorpå de udvalgte egenskaber vil danne grundlag for det første indhold i den fælles cuneco egenskabsdatabase. Skulle der blive identificeret områder af egenskaber, der ikke er dækket af kørende projekter, er det muligt at nedsætte særskilte egenskabsdataprojektgrupper inden for disse områder. Projektgrupperne er som udgangspunkt sammensat af praktikere fra branchen, som i hverdagen arbejder med projektering, udførsel eller drift af byggeri og anlæg, herunder informationsudveksling mellem rådgivere, entreprenører, driftsherrer og bygherrer. Såfremt der ikke deltager ITuddannede i projektgrupperne, bør resultaterne efterfølgende valideres af IT-uddannede personer for at sikre IT-implementerbarheden International koordinering I det videre arbejde med egenskabsdata er det vigtigt at den internationale koordinering indarbejdes i processen omkring udvikling af egenskabsdata. Dette sikres til dels ved, at egenskaber får engelske navne, at de i videst muligt omfang mappes til IFC og IFD samt ved at definitionerne på egenskaber kobles på internationale definitioner af tilsvarende egenskaber. Dette arbejde vil som udgangspunkt ikke være indeholdt i det projektarbejde, som omhandler definition, navngivning og beskrivelse af egenskabsdata. Arbejdet med strukturering og mapning af egenskaber til IFC og IFD vil foregå som et parallelt projekt med deltagelse af 1-2 personer, som har stor viden omkring både IFC og IFD. Den løbende koordinering i forhold til fremtidige opdaterede versioner af IFC- og IFD-standarder vil foregå ved at sammenholde indholdet af cunecodatabasen med de changelogs, der udgives af buildingsmart-samfundet. Da cunecos egne egenskabsdatasæt er navngivet med _DK i forlængelse af 36