På vei mot et desentralisert felles CDE med Linked data og Solid økosystemet


Dette er en vitenskapelig artikkel skrevet av Jeroen Werbrouck, Pieter Pauwels, Jakob Beetz og Léon van Berlo. Denne er oversatt til norsk og supplert med linker, figurer og kommentarer av Håkon Reisvang. Håkon sprer informasjon til den Norske BAE næringen, gjennom 2 satsninger. EVU kurset BIM i industri 4.0 på NTNU gjøvik (blir tilgjengelig på NTNU sine nettsider ila en måneds tid) og Nordic Building Room. Han har et stort driv for å implementere Linked data i BAE næringen og samarbeider med Amerikanske graphMetrix Inc, om å utvikle Linked data programvareutviklingsverktøypakken Trinity, som utnytter Solid Økosystemet. Det er avholdt et møte mellom Jeroen, Håkon og graphMetrix i forkant av denne oversettelsen. Artikkelen er ment som et gratis oppslagsverk til den norske BAE næringen.

Sammendrag

Med fremveksten av BIM, fanger byggebransjen raskt den digitale revolusjonen som har økt produktiviteten i praktisk talt alle økonomiske sektorer. I dagens praksis ligger fokuset på BIM på utveksling av dokumenter, ofte gjennom proprietære formater som utveksles ved bruk av Industry Foundation Classes (IFC).

Med webteknologier som RDF, OWL og SPARQL blir et data- og nettbasert BIM-paradigme imidlertid innen rekkevidde. Desentralisering av data og frigjøringen av informasjon og applikasjoner vil styrke en mer generell adopsjon av Big Open BIM, og forventes å senke BIM-terskelen for mindre selskaper som er aktive i forskjellige faser av bygningens livssyklus.

Siden et av løftene fra Semantisk Web og Linked Data er en svært forbedret interoperabilitet mellom forskjellige fagområder, er det ikke nødvendig å finne opp hjulet på nytt, for oppsett av en infrastruktur som støtter et slikt nettverk av desentraliserte verktøy og data.

I denne artikkelen vurderer vi spesifikasjonene levert av Solid-prosjektet (Inrupt Inc.), et Linked Data - basert økosystem for sosial media. Selv om bruken Solid-økosystemet er desentralisering av data og applikasjoner til sosial media formål, merker vi en betydelig overlapping med de nylige ambisjonene og utfordringene for en nettbasert BAE næring.

Dette inkluderer standardiserte datarepresentasjoner, rolle- eller aktørbasert autorisasjon og autentisering og behovet for modulære og utvidbare applikasjoner, dedikert til en spesifikk brukssak.

Etter en kort introduksjon til Linked Data og dens applikasjoner i byggenæringen diskuterer vi nåværende løsninger for bygging av dataadministrasjon (Common Data Environments, multi-models, etc.).

For å oversette disse tilnærmingene til en Linked Data - kontekst med minimal innsats og maksimal effekt, gjennomgår vi deretter Solid-spesifikasjonene for bruk i et konstruksjonsorientert webøkosystem.

Som et bevis på konsept diskuterer vi oppsett av en webtjeneste for oppretting og styring av koblede bygningsdata, generert med Solid-React-generatoren. Denne applikasjonen er tenkt som en bro mellom flere datalagre for forskjellige prosjektinteressenter og sluttbrukeren. Det fungerer som et grensesnitt til et distribuert felles datamiljø (CDE) som også tillater generering av multimodeller.

Kommentar: Det er undertegnedes antakelse at buildingSMART er enige i dette, iom at ildsjelene har lagt ned LDWG og forsetter arbeidet i W3C Linked Building Data Community Group. bS Norge er imidlertid i gang med Linked data i dette oppstartsmøtet fra 17 mars

Introduksjon

Byggeindustrien er en av de mest fragmenterte næringene i hele verden. Samtidig er det også blant de minst digitaliserte industriene, bare foran ‘Landbruk og jakt’. Selv om den siste tiden med BIM implementering, har lukket gapet noe, er det flere utfordringer som fremdeles overvinnes før sektoren når det fulle potensialet som digitaliseringen gir. Med andre ord, bruken av integrerte, interoperable data, utvekslet gjennom tilkoblede webtjenester, eller å nå 'BIM Trinn 3' som definert i den beryktede Bew-Richards modellen).

Hovedmålet med nettbasert BIM er å gi et svar til dataøyer (siloer) som kompliserer tapsfri utveksling og samarbeid mellom fagområder som fokuserer på det bygde miljøet. Disse fagområdene danner AECO-industrien (Arkitektur, ingeniørfag, konstruksjon og drift).


Figur 1: BIM-nivåene

Linked data teknologier anses som veldig lovende å nå et så høyt nivå av interoperabilitet. Disse teknologiene er avhengige av RDF (Resource Description Framework), som er en datamodell som er standardisert som en del av Sematisk Web-teknologistacken (se fig t.h.) bruk av RDF kan individuelle datakonsepter knyttes til hverandre i form av Triples. RDF

Triples kan forstås som helt grunnleggende setninger, og knytter et subjekt til et objekt ved hjelp av et predikat som angir det eksakte forholdet mellom de to.


Kommentar: Eks: Dør(Subjekt) er en del av (predikat) Vegg(objekt)



For å sikre at hvert dataelement er unikt identifiserbart over nettet, er det preget av en Uniform Resource Identifier URI (Uniform Resource Identifier). Denne strategien, som er hovedforskjellen mellom RDF og andre eksisterende datamodeller, gjør det mulig å semantisk berike informasjon på en åpen verden: alt kan sies om hva som helst, noe som åpner muligheter for tverrfaglig samarbeid. På grunn av den strukturerte representasjonen av data i form av en nettgrafisk graf (grafdatabase), er digitale agenter dessuten i stand til å tolke disse dataene semantisk og bruke dem til spesifikke formål med minimal menneskelig intervensjon.

Det kan skilles mellom terminologien som brukes for å beskrive data (f.eks. En taksonomi, en type) og de faktiske dataindividene som er semantisk koblet ved hjelp av disse strukturene (f.eks. Et spesifikt objekt). Førstnevnte blir referert til som TBOX

(‘Terminological’), sistnevnte som ABOX (‘Assertion’). Kunnskapsmodeller for å definere konseptuelle domeneskjemaer er stort sett på TBOX-nivå. Slike skjemaer kalles ‘vokabularer’ eller ‘ontologier’ og gir semantisk mening til visse dataelementer. Kombinasjonen av flere vokabularer gjør det mulig å sette opp komplekse modeller av reelle problemer.


Bruken av Linked Data-konsepter for AECO Industrien har blitt dokumentert flere ganger nå fordi det alvorlig kan øke interoperabiliteten mellom fagdisipliner og samarbeid mellom interessenter. Linked-data gjør det mulig å konstruere vokabularer for hver relatert underdisiplin, koblet med hverandre i et nøytralt format og distribuert over flere servere.

Dette tillater applikasjoner som kan brukes i forskjellige aspekter av det bygde miljøet, samt kan koble og utveksle informasjon uten tap av informasjon. Det gjør det også mulig å koble til åpne data på nettet, for eksempel kontekstuell informasjon (f.eks. Geospatiale, offentlige, historiske eller værdata). Siden vokabularer inneholder informasjonen for å tolke dataene på en semantisk måte, kommer automatisk resonnement og regelkontroll innen rekkevidde. Med dette i bakhodet jobber flere forskere for tiden med å gjøre Linked Data-basert BIM mer moden. Først foreslått i (Beetz et al., 2005), ble installasjonen av en Linked Data-basert versjon av IFC offisielt godkjent som Otologien ifcOWL. Ettersom ifcOWL dekker hele IFC-skjemaet, er det imidlertid veldig stort og følgelig ikke veldig fleksibelt til å håndtere temaer som ikke er tilstrekkelig dekket i IFC-standarden, for eksempel eksisterende bygninger, Geographic Information Systems (GIS), Facility Management (FM) eller sirkulær økonomi.

Et nytt paradigme foreslås derfor av W3C Linked Building Data Community Group, rettet mot utviklingen av mer modulære vokabularer som hver tar for seg et spesifikt bygningsrelatert emne (Rasmussen et al., 2017). Den største fordelen med slike modulære Linked Data-vokabularer fremfor tradisjonelle, monolitiske, domenespesifikke informasjonsmodeller som IFC-skjemaene er deres modularitet, noe som øker fleksibiliteten til å møte spesifikke utfordringer.


Selv om det er gjort mye forskning og standardisering angående Semantisk Web, generelt så vel som for bygging, forblir antallet applikasjoner som effektivt bruker potensialet begrenset. Linked Data-teknologier har en bratt læringskurve, og det er litt av et implementeringsgrensesnitt for utviklere å aktivt bidra til et sammenkoblet nettverk av web applikasjoner. For å stimulere det verdensomspennende utviklermiljøet, og for å skille personopplysninger fra applikasjonene som bruker det, ble det nylige Solid-prosjektet (SOsial LInked Data) grunnlagt. Den tar sikte på et desentralisert økosystem for sosiale nettapplikasjoner, der brukerne eier dataene sine selv (Brukere har dataen lagret i en solid pod, med full kontroll over hvilke data de deler med hvilke applikasjoner) og lar eksterne (mikro) applikasjoner bruke dem til et bestemt (sosiale medier) formål. Imidlertid er sosiale medier bare en brukssak valgt av Solid-teamet for å illustrere konseptet. Det samme settet med spesifikasjoner og verktøy kan også brukes til andre domener, spesielt for fagområder like fragmenterte og desentrale som byggenæringen.

Flere forskningsprosjekter fokuserer på utvikling av kunnskapsmodeller for å beskrive det bygde miljøet i en semantisk web-sammenheng. For å implementere disse kunnskapsmodellene og gå mot BIM Trinn 3, må brukbare applikasjoner (f.eks. Trinity) utvikles. Modulære webapplikasjoner for byggenæringen, i stand til å kommunisere med hverandre og utveksle forskjellige data med bruk av HTTP og JSON, ble nylig introdusert som 'BIM bots '4, ofte bygget ved hjelp av BIM bot kompatible BIMserver rammeverket, en velkjent implementering av modell-severe som er basert på IFC.

Når vi går et skritt videre, kan ideen om BIM-roboter utvides med Linked Data, og utvide spekteret til temaer som ikke vanligvis dekkes av IFC. Siden Semantisk Web-teknologistacken tilbyr muligheten til å koble til forskjellige domener, er det ikke nødvendig å starte et spesifikt Linked Data-økosystem for konstruksjon.

Med dette i bakhodet diskuterer denne presentasjonen bruken av spesifikasjonene gitt av Solid-prosjektet. Når vi vurderer en samarbeidsmåte for håndtering av prosjektdata, som det første trinnet for et nettverk av koblede bygningsdataverktøy, implementeres en prototypisk ledelsestjeneste i solid økosystemet som bevis på konseptet ved hjelp av Solid-React-generatoren, som skjuler autentiseringens kompleksitet, autorisasjon, datalagring etc.


Samarbeid strategier for byggeprosjekter

Forskjellige strategier eksisterer nå for å nå et mer strømlinjeformet samarbeid innen byggeprosjekter. En CDE (Common Data Environment) er et virtuelt lagringssted for innsamling og administrasjon av dokumentasjon av byggeprosjekter, hovedsakelig tilbudt som skytjeneste. Fordi all prosjektinformasjon styres fra ett sted, reduseres sjansen for misforståelse og tap av informasjon sterkt. Tilgang til visse dokumenter kan defineres av prosjektets informasjonsleveringshåndbok (IDM), basert på den internasjonale BuildingSMART-standarden for pakking og strukturering av Informasjonskrav (EIR, PIR, AIR). Eksempler på kommersielle CDE-er er for eksempel Autodesk's BIM 360 og Trimble Connect. CDE-er kan optimaliseres for å arbeide med visse dataformater, enten proprietære eller åpne. Standarder som IFC gjør det mulig å utveksle informasjon mellom applikasjoner fra forskjellige programvareleverandører, som i de fleste tilfeller bruker proprietære dataformater. BIMserver-plattformen (bimserver.org) implementerer IFC i en modellserver og lar utviklere bygge webtjenester eller plugins som kan kobles til den delte IFC-databasen og utveksle data via et felles API (f.eks. BIMSie). Nyere utvikling viser at de viktigste leverandørene av CDE er åpne for å utvikle et standardisert åpent API for CDE-er. Dette initiativet startet nylig som en oppfølging fra det tyske DIN SPEC (91391-1 / 2) initiativet som definerer funksjonene og forventningene fra en CDE.


En tilnærming relatert til CDE-er, men mer fokusert på beholderstrukturen der

prosjektinformasjon kan lagres, er de såkalte multimodellene. Den siste utviklingen innen dette domenet er ICDD (Information Container for Data Drop ), som er i sluttfasen av standardisering som ISO 21597. Det er etterfølgeren til den nederlandske COINS-standarden og følger en tradisjon med ontologibasert multimodell ledelse. I sine egne ord er ICDD utviklet ‘som svar på byggebransjens behov for å håndtere flere dokumenter som én informasjonslevering eller datadrop.



Den interne strukturen er basert på to ontologier: en Container-ontologi og en Linkset-ontologi. Da førstnevnte definerer klassene og egenskapene som er brukt for å beskrive metadata om containeren, gir sistnevnte definisjonene for de semantiske koblingene mellom dokumenter. Standarden gjør det mulig å referere til identifikatorer på et underdokumentnivå, for eksempel individuelle IFC GUIDer eller pikselsoner i et bilde. En ICDD-container kan betraktes som en semantisk tilkoblet ‘dump’ -mappe med tilgjengelig prosjektinformasjon, og kan for eksempel brukes når prosjektdata må overføres fra en prosjektinteressent til en annen. En beholder i * .iccd-format (ved hjelp av en ZIP-komprimering) har en fast struktur, som inneholder undermapper med de viktigste ontologiene, 'payload dokumentene' (f.eks. Bilder og IFC-filer) og 'payload-tripplene' for forholdene mellom disse dokumentene. Hovedmappen inneholder en index.rdf-fil som inneholder dokumentene til prosjektet og noen metadata. Content.rdf-filen som er lagret i mappen ‘payload-triples’, kan også referere til eksterne dokumenter eller URI-er. En oversikt over ICDD-strukturen er gitt i fig. 2, som viser mappestrukturen og en delmengde av et lenkesett i Turtle-format.

I dette avsnittet ble det gitt en kort introduksjon til CDE-er og ICDD-standarden for flermodellcontainere. Mens CDE-er fokuserer på et skymiljø forbedret for samarbeid, tillater koblede databaserte multimodeller å opprette spesifikke koblinger mellom prosjektdokumenter og underdokumentinformasjon. En koblet databasert CDE vil trenge å kombinere mulighetene som tilbys av CDE-er, samtidig som de tillater å etablere koblinger mellom RDF-data og dokumenter, på et finkornet datanivå. På denne måten kan prosjektkilder som bilder, punktskyer, geometri etc. kobles til RDF-grafer om topologi, produkter og egenskaper. I neste avsnitt gjennomgår vi spesifikasjonene til Solid økosystem for bruk i en slik koblet databasert CDE.


Solid Spesifikasjon

Den første brukssaken til det solide økosystemet er sosiale medier. (SOcial LInked Data) Frigjøringen av applikasjoner og data lar brukerne være eieren av sine egne data og la applikasjonene som passer deres behov mest, få tilgang til disse dataene. Fra et mer generelt perspektiv er det en bevegelse som tar sikte på å realisere nettet 'slik det opprinnelig ble sett for seg' av Tim Berners Lee:

· personlig datalagring,

· standard kommunikasjon mellom apper og

· bruk av et 'universelt' dataformat i form av RDF.

Frigjøringen av apper og data er like relevant for byggesektoren som for sosiale data. BIMserver innser dette innenfor kontekst av IFC; Solid rammeverket kan være en kandidat for å gjøre dette i en Linked data-sammenheng.

I den følgende delen gjennomgår vi hovedspesifikasjonene for Solid rammeverket, og foreslår hvordan de kan implementeres for byggeprosjekter.


Identifisering og autentisering

I Solid skjer identifisering av aktører gjennom WebID’er. I avsnitt 1 ble det opplyst at i Linked data identifiseres alle ‘ressurser’ gjennom en unik identifikator over nettet, en URI. Brukt på WebID-er betyr det at enhver aktør kan ha sin egen URI, som kan forholde seg til andre ressurser (f.eks. Personopplysninger eller andre menneskers WebID-er) og kobles til andre ressurser også. Dette genererer en global ‘sosial graf’ med grunnleggende forhold mellom en person, hans data og andre menneskers data. Innenfor Solid brukes WebID som en URL (Uniform Resource Locator), som er en spesifikk type URI som, bortsett fra å identifisere ressursen, også gir tilgang til den. Et eksempel på et WebID kan være:

https://jwerbrouck.solid.community/profile/card#me.


Den identifiserer både ressursen som skal inkluderes i trippel som lenker til denne personen, og nettadressen, som gir tilgang til hans personlige datakort. Dette kortet er en del av 'datapoden' til aktøren: serveren som inneholder en innboks, en offentlig mappe og en privat mappe. I henhold til spesifikasjonene vil en 2019-oppdatering inneholde et avsnitt der tilgangsrettigheter for tredjepartsapplikasjoner kan administreres: lese, skrive, legge til og kontrollere. I skrivende stund administreres dette bare ved å logge på applikasjonen med ditt personlige webID. Dette systemet med datapoder som lar bestemte apper få tilgang til dataene, er den viktigste forskjellen med dagens sosiale nettverk, som krever at brukerne laster opp dataene sine. WebID fungerer også som grunnlag for autentisering av aktører, i stedet for brukernavn, ved å bruke WebID-TLS-protokollen og kryptografiske sertifikater generert av nettleseren.


Autorisasjon

For å avgjøre om en bestemt aktør (person eller applikasjon) har tilgang til bestemte data, brukes en RDF-basert autorisasjonsmekanisme kalt ‘Web Access Control’ (WAC) aktører kan identifiseres med sine WebID-er, som er lagret i * .acl-grafer som oppgir hvilke WebID-er som skal få lov til å lese eller oppdatere data.

Spesifikasjonen gjør det også mulig å referere til grupper av brukere i stedet for spesifikke bruker.

En * .acl-fil kan kobles til en hel mappe (for eksempel de grunnleggende mappene for offentlige og private data), men kan også kartlegges på en mer finkornet måte til undermapper eller individuelle filer eller RDF-grafer. For øyeblikket tillater ikke spesifikasjonen kartlegging på ressursnivå, noe som kan være gunstig for Linked data baserte byggeprosjekter.

Innholdsrepresentasjon

Generelt utgjør datapoder en forskjell mellom Linked Data-ressurser (f.eks. I form av Turtle, JSON-LD, etc.) og ikke-Linked Data-ressurser (f.eks. Bilder, PDF-filer, etc.).

Alle ressursene er gruppert i undermapper for enten den private eller den offentlige datamappen. Som angitt i Autorisasjon avsnittet, kan tilgangsrettigheter reguleres per graf eller dokument, basert på .acl-spesifikasjonen.


Solid programvareutviklingsverktøypakke


Kommentar: Trinity er både en grafgenerator og programvareutviklingsverktøypakke, se video her.

Som nevnt er antallet applikasjoner som bruker koblede data fortsatt begrenset. Siden et desentralisert og distribuert økosystem som Solid er avhengig av tredjepartsutviklere for applikasjonsutvikling, må det senke denne utviklingsterskelen. Med dette i bakhodet leveres en dedikert programvareutviklingsverktøypakke for programmering i React og Angular. Dette inkluderer en generator som forhåndskonfigurerer Solid spesifikasjonene (f.eks. For sikkerhetsinnstillinger), slik at utviklere kan fokusere på funksjonaliteten de ønsker å implementere, i stedet for å implementere spesifikasjonene selv. Det inkluderer også Comunica-rammeverket for Query’e /Forespørre info fra Linked data på nettet, med SPARQL (SPARQL-protokoll og RDF Query Language)

Ellers finnes det mindre ordrike og mer tilgjengelige varianter som GraphQL-LD. Bruken av disse mer tilgjengelige spørrespråkene forventes også å forbedre utviklingshastigheten for Linked Data-applikasjoner.


Solid for byggeprosjekter

Ovennevnte spesifikasjoner for Solid kan lett implementeres for en AECO-orientert CDE, muligens utvidet mot et økosystem av Linked Data BIM-roboter (Agents). Fremtidig forskning bør bestemme den optimale konfigurasjonen, selv om vi i denne første artikkelen foreslår en foreløpig tilnærming, som også vil bli brukt i proof-of-concept-anvendelsen.


Kommentar: 10X Construction kommer til å utvikle Trinity BIM roboter, så snart grafgeneratoren er optimalisert for Norske byggeprosjekter.


I denne arbeidsflyten;

· oppretter prosjektlederen en privat prosjektundermappe i sin datapod.

· Alle prosjektinteressenter har sin egen datapod også,

· og får URI for prosjektlederens hovedmappe. (Dette betyr ikke at de har tilgang til filene som er inneholdt, da dette kan administreres individuelt).

· Denne prosjektmappen skal inneholde minst to grafer i den private dataseksjonen.

· Den første definerer minimal prosjektinformasjon; prosjektets 'skjelett' i form av dets topologi. (Vi foreslår å bruke den modulære BOT (Building Topology Ontology) (Rasmussen et al., 2017) som anbefalt av W3C Linked Building Data Community Group.) BOT gjør det mulig å identifisere forskjellige soner i en bygning (område, bygning, etasje, plass) og definere forholdene mellom dem.


· Den andre grafen inneholder WebID-er fra forskjellige interessenter og deres funksjon (er) i prosjektet.

· Denne interessentgrafen vil bli brukt til å definere tilgangsrettigheter basert på rollen i prosjektet.

· I tilfelle en overlevering av prosjektdataene skjer, eller roller byttes i ett prosjekt, kan tilgangsrettigheter derfor umiddelbart oppdatere.

· Prosjektinteressenter oppretter deretter en prosjektmappe i sin egen pod også, og laster opp informasjonen som er deres ansvar, mens de kobler den til det generelle prosjekt URI fra lederen.

· De kan be om tilgang til prosjektinformasjon fra andre interessenter, for å kunne koble til denne informasjonen også.

· Å gi tilgang til annen prosjektinformasjon kan gjøres av lederen (som som standard har tilgang til hele prosjektdatabasen) eller av den ansvarlige interessenten.

Slik begynner et sammenkoblet, virtuelt miljø å eksistere, som kobler dataene og dokumentene fra prosjektinteressentene til en nettbasert graf; et koblet databasert fellesdatamiljø.


Ideelt sett er det bare binær informasjon (bilder, punktskyer) som lagres som dokumenter, mens annen informasjon som topologi og produktdata lagres i en RDF-graf.

Imidlertid støtter den beskrevne arbeidsflyten også en mer tradisjonell dokumentbasert tilnærming: en prosjektstyringsapp som implementerer ICDD-ontologiene, kan lett generere en ICDD-dumpfil av prosjektet, og speile den distribuerte online-modellen.


Bortsett fra denne grove arbeidsflyten, kan Solid sin programvareutviklingsverktøypakke og implementering av for eksempel GraphQL-LD for å lette spørringene, stimulere utviklingen av Linked Data-applikasjoner for AECO industrien betydelig. En generell arbeidsflyt for justering av slike applikasjoner må gjøres i fremtiden, slik at de automatisk kan kommunisere med hverandre og utveksle informasjon som er nødvendig for et visst brukstilfelle.


Denne arbeidsflyten kan være basert på IDM- og MVD-spesifikasjonene og inkludere en metode for å beskrive brukstilfeller på en modulær måte, der verktøy kan lenkes sammen, automatisk validere innganger og utganger, for eksempel med bruk av SHACL (Shapes Constraint Language)


Slike verktøy kan deretter bruke RDF-data i de distribuerte prosjektpodene for avansert resonnement, simulering, modellberikelse etc. For øyeblikket er imidlertid det første trinnet å sette opp en prototypeapplikasjon for grunnleggende styring av bygningsdata.


Kommentar: Når vi nå skal i gang med Ontologibygging (definere konsepter) kan det være lurt å samkjøre med Open AR Cloud sin RML (Reality modeling language) arbeidsgruppe for OSCP (Open Spatial Computing Platform), og tenke ‘Systems approach to ontology’. Her er mye av jobben som må gjøres allerede utført i graphMetrix ontologien. Hvis du jobber med dette, ønsker vi kontakt (mailto:hakon.reisvang@i4technology.no)


OSCP: Geopose-1, RML-2, Access-3


Bevis for konseptet (PoC): ConSolid

I dette avsnittet vil arbeidsflyten omtalt i kapittelet ‘Solid for byggeprosjekter’ tjene som en retningslinje for utviklingen av en rudimentær applikasjon for bygningsdatahåndtering, som har tittelen ‘ConSolid’ (Construction Solid). I det ideelle tilfellet hjelper ConSolid-appen i følgende emner for prosjektledelse:


• Konfigurasjon av byggeprosjektet og dets topologi

• Semantisk berikelse av et byggeprosjekt med geometri, produktdata og egenskaper

• Konfigurasjon av interessentene og deres rolle i prosjektet

• Laste opp dokumenter til å bygge prosjektmapper

• Koble dokumentbasert informasjon til hverandre og til RDF-grafer (eks Trinity PDF&Specs)

• Validering av den distribuerte modellen med forhåndsdefinerte valideringsformer (f.eks. SHACL)

• Forespørsel om byggeprosjektinformasjon

• Generering av ICDD-prosjektcontainere


Testapplikasjonen ble generert med Solid React-generatoren. Ettersom utviklingen er i gang, har ikke all funksjonalitet blitt implementert i skrivende stund: innledende arbeid har fokusert på implementering av prosjekt- og topologioppretting, rollefordeling og opplasting, kobling og spørring av prosjektinformasjon av prosjektlederen.

Semantisk berikelse av prosjektet med produktdata, egenskaper og geometrisk informasjon er ikke implementert ennå. Strategier for å integrere SHACL-validering i ConSolid-verktøyet er omtalt i BIM4REN prosjektet under artikkelen ‘A Checking Approach for Distributed Building Data’


Grunnleggende funksjonalitet

Den genererte applikasjonen inkluderer påloggingsfunksjonalitet med egne WebID’er. Etter innlogging lagres WebID’en, noe som gjør at applikasjonen kan utføre handlinger med dataene som er lagret i brukerens pod. I den nåværende implementeringen skiller vi (bortsett fra de generelle kategoriene Hjem og Profil) mellom tre (røde sikler) hovedfaner;


• Topologi (Topology)

• Roller (Roles)

• Koble til (Connect) for å styre den grunnleggende informasjonen om bygningen, interessentene og deres roller og tilkoblingen av distribuerte prosjektdata.


Prosjekttopologi

Hvis brukeren er eier av et prosjekt, kan det velges i navigasjonslinjen og lastes fra de distribuerte podene til interessentene (grønn sirkel figur over).

Den grunnleggende bygningstopologien vises deretter i fanen ‘Topologi’, der den kan oppdateres.

Dokumenter kan lastes opp til pod og lenkes til bestemte soner i bygningen, som et alternativ til den mer avanserte koblingen i fanen 'Connect'. Hvis det ikke er opprettet noen prosjekter ennå, kan et nytt prosjekt opprettes fra bunnen av, med angivelse av den grunnleggende topologien og innstilling av poderen som prosjektleder. Som nevnt tidligere er ontologien som brukes til topologibeskrivelse BOT (Mads Rasmussen), selv om andre ontologier som ifcOWL også kan brukes.

Kommentar: undertegnede anbefaler ikke ifcOWL, se her for ontologier W3C anbefaler

Rolletildeling

Fanen ‘Roller’ lar prosjektlederen tildele visse roller til visse WebID-er. Disse rollene er lagret i en graf i hovedprosjektpoden (ved bruk av FOAF) og kan brukes til å administrere tilgangsrettigheter. Et skjema kan utvikles med noen standard tilgangsrettigheter som er kartlagt til bestemte roller, for automatisk å stille inn rettighetene som forekommer mest. Rollegrupper kan konfigureres fra disse dataene, noe som betyr en mer fleksibel tilnærming enn bare personbaserte tilgangsrettigheter.

Datatilkobling og generering av containere

I kategorien ‘Koble til’ kan brukeren laste opp filer til prosjektpoden. En interessent som er logget inn kan laste opp filer til podden hennes. Prosjektfiler som brukeren har tilgangsrettigheter til, kan knyttes til hverandre, så vel som dokumenter som på underdokumentnivå. Som indikert under PoC kan disse prosjektdokumentene være strukturert som Linked data så vel som ustrukturert (pdf dokumenter).


For å tillate optimal kobling av dokumenter og tredobbel, kan forskjellige strategier brukes for forskjellige filformater. Siden ICDD-spesifikasjonen ikke oppgir hvordan underdokumentidentifikatorer for bestemte dokumentformater skal defineres, er det ikke noe avtalt system som refererer til IFC GUIDS, pikselsoner osv. Ettersom dette er et eget problem som ikke anses som en del av dette fungerer, er denne prototypen for øyeblikket begrenset til å koble og vise RDF grafer og bilder. I fremtidige versjoner kan 3D-

modellvisere, tekstredigerere, etc. implementeres for å støtte et bredere utvalg av dokumenter.


For å forenkle query’en av Linked Data filer er en testmotor for GraphQL-LD implementert (fig t.h). Dette betyr at en sluttbruker ikke trenger å vite detaljene i Linked Data for å query’e om tilgjengelig informasjon. Søkeresultatene kan deretter velges individuelt for å koble til andre RDF-ressurser, dokumenter eller underdokumentidentifikatorer.


Laste opp og koble sammen dokumenter i fanen Koble til. Koblede datafiler kan spørres med ikke-spesialiserte språk som GraphQL-LD eller LDflex


Siden solid pods også følger en containerlignende struktur, bør implementeringen av funksjonalitet for å generere en ICDD-container være ganske grei.


Testing

Full testing av verktøyets funksjonalitet har ikke skjedd i skrivende stund, selv om de forskjellige modulene (prosjektoppretting, topologi, spørring) er testet separat og iterativt under utviklingsprosessen. Det ligger innenfor ambisjonene å simulere et mer komplett prosjekt når de ovennevnte modulene er tettere integrert med hverandre.


Konklusjon

I denne artikkelen foreslo vi bruk av Linked Data for semantisk tilkoblede CDE’er. På grunn av universaliteten til RDF, kan slik CDE spille en sentral rolle i et nettverk av modulbaserte applikasjoner som hver for seg ser en viss aktivitet i Building Life Cycle. Omfanget av slike applikasjoner er derfor ikke begrenset til 'typiske' byggeaktiviteter, men kan også omfatte tilstøtende domener som historiske eller geografiske data, Facility Management, sirkulær økonomi etc. Modulære domenemodeller, som foreslått av LBD Community Group, muliggjør en mer fleksibel tilnærming til prosjekter som jobber med forskjellige data. Det ble vist at ideen bak Solid økosystemet ligner på begrepet BIM-bots, men da i et Linked Data-miljø. En kort oversikt over de grunnleggende spesifikasjonene som tilbys av dette økosystemet for sosialkoblede data ble gitt, og potensialet for å håndtere byggeprosjekter ble illustrert. For å fullføre ble en prototype-applikasjon ‘ConSolid’ diskutert, ved bruk av en programvareutviklingsverktøypakke som forhåndskonfigurerer spesifikasjonene for applikasjonen. Denne tjenesten er fortsatt i en veldig tidlig utviklingsfase og dermed svært eksperimentell. Likevel viser noe grunnleggende funksjonalitet at en desentralisert styring av bygningsinformasjon er oppnåelig med den tilgjengelige teknologistacken.


Fremtidig arbeid

Siden dette arbeidet bare er en introduksjon, kan fremtidig arbeid fokusere på flere aspekter. Et aspekt er å videreutvikle ConSolid-applikasjonen mot et mer modent verktøy som kan brukes i praktiske situasjoner. Bortsett fra den grunnleggende implementeringen som er omtalt i PoC, må vokabularer (ontologi) for å beskrive produktinformasjon og egenskaper implementeres for å kunne skape realistiske prosjekter. Dette er en forutsetning for å teste de overordnede egenskapene til brukssaken i et senere utviklingsstadium. Et annet fokus bør ligge på hvordan flere verktøy kan få tilgang til byggeprosjektdataene og kommunisere med hverandre. For eksempel vil etablering av en kobling med (eksisterende) modelleringspakker gjøre opprettelsen av en grunnleggende Linked Building Data-modell mer intuitiv.


På grunn av desentraliseringsprinsippet, kan andre webapplikasjoner som er autorisert til å hente prosjektdata ytterligere berike eller analysere prosjektet, f.eks. ved å utføre simuleringer for byggets ytelse. Når mange verktøy er dedikert til en liten oppgave, kan de brukes som atombyggesteiner i en verktøykjede som adresserer større brukssaker. Semantiske webteknologier som SHACL tillater validering av informasjonen som utveksles i en slik kjede. Å ha en måte å konfigurere og koble til flere, modulbaserte verktøy, bør også tillate at bygningsdisipliner som ligger utenfor konstruksjonen kan samarbeide og bruke de samme dataene. Slike scenarier krever imidlertid en grundigere sammenkobling av informasjon på datanivå: i stedet for å bli lagret i filer (ikke filer), må den tilgjengelige informasjonen bli representert i RDF-format så mye som mulig.

Med dette i tankene håper vi at dette arbeidet kan bidra til fremskritt i BIM-samfunnet mot en åpen BIM-praksis som er preget av integrerte webtjenester og interoperable data.

- Håkon Reisvang 30.03.2020

Anerkjennelser

Forfatterne vil anerkjenne støtten fra både Special Research Fund (BOF) fra Ghent University og BIM4REN-prosjektet, som har mottatt finansiering fra EUs Horizon2020 Research and Innovation Program under tilskuddsavtale nr. 820773.

Bibliografi

• Beetz, J., van Berlo, L., de Laat, R., & van den Helm, P. (2010). BIMserver. org–An open source IFC model server. Proceedings of the 27th CIB W78 Conference on Information Technology in Construction, 8.

• Beetz, J., Van Leeuwen, J. P., & De Vries, B. (2005). An Ontology Web Language Notation of the Industry Foundation Classes. Proceedings of the 22nd CIB W78 Conference on Information Technology in Construction, 2006, 670. Technical University of Dresden.

• Berners-Lee, T., Dimitroyannis, D., Mallinckrodt, A. J., & McKay, S. (1994). World Wide Web. Computers in Physics, 8(3), 298.

• Berners-Lee, T., Hendler, J., & Lassila, O. (2001). The Semantic Web. Scientific American, 284(5), 28.

• Gürtler, M., Baumgärtel, K., & Scherer, R. J. (2015). Towards a workflow-driven multi-model BIM Collaboration Platform. Working Conference on Virtual Enterprises, 235. Springer.

• Hollenbach, J., Presbrey, J., & Berners-Lee, T. (2009). Using RDF Metadata to enable Access Control on the Social Semantic Web. Proceedings of the Workshop on Collaborative Construction, Management and Linking of Structured Knowledge (CK2009), 514, 167.

• Mansour, E., Sambra, A. V., Hawke, S., Zereba, M., Capadisli, S., Ghanem, A., … Berners-Lee, T. (2016). A Demonstration of the Solid Platform for Social Web Applications. Proceedings of the 25th International Conference Companion on World Wide Web, 223. International World Wide Web Conferences Steering Committee.

• McKinsey & Company. (2015). Imagining Construction’s Digital Future. Retrieved from https://www.mckinsey.com/industries/capital-projects-and-infrastructure/our-insights/imagining-constructions-digital-future

• Oraskari, J., & Törmä, S. (2016). Access Control for Web of Building Data: Challenges and Directions. EWork and EBusiness in Architecture, Engineering and Construction, 45.

• Pauwels, P., & Terkaj, W. (2016). EXPRESS to OWL for Construction Industry: Towards a recommendable and usable ifcOWL Ontology. Automation in Construction, 63, 100.

• Pauwels, P., Zhang, S., & Lee, Y.-C. (2017). Semantic Web Technologies in AEC Industry: A Literature Overview. Automation in Construction, 73, 145.

• Rasmussen, M., Pauwels, P., Lefrançois, M., Schneider, G. F., Hviid, C., & Karlshøj, J. (2017). Recent Changes in the Building Topology Ontology. LDAC2017-5th Linked Data in Architecture and Construction Workshop.

• Schapke, S. E., Katranuschkov, P., & Scherer, R. J. (2010). Towards ontology-based management of distributed multi-model project spaces. Proceedings of the 27th CIB W78 Conference on Information Technology in Construction.

• Taelman, R., Van Herwegen, J., Vander Sande, M., & Verborgh, R. (2018). Comunica: a modular SPARQL Query Engine for the Web. International Semantic Web Conference, 239. Springer.

• Taelman, R., Vander Sande, M., & Verborgh, R. (2018). GraphQLLD: Linked Data Querying with GraphQL. ISWC2018, the 17th International Semantic Web Conference.

• Törmä, S. (2013). Semantic Linking of Building Information Models. 2013 IEEE Seventh International Conference on Semantic Computing, 412. IEEE.

• van Berlo, L. (2015). BIM Service Interface Exchange (BIMSie). Retrieved from https://www.nibs.org/page/bsa_bimsie

• Verborgh, R. (2018). Designing a Linked Data Developer Experience. Retrieved 25 April 2019, from https://ruben.verborgh.org/blog/2018/12/28/designing-a-linked-data-developer-experience/

• Werbrouck, J., Pauwels, P., Senthilvel, M., & Beetz, J. (2019). A checking approach for distributed building data. Presented at the 31st Forum Bauinformatik, Berlin, Germany.

84 visninger
 

© 2020 BY I4TECHNOLOGY. Proudly created with Wix.com

FOLLOW

KONTAKT OSS

i4 logo.png

-Vi hjelper Norge bygge smartere!