Old Dutch conference write-up¶

I found an old write-up of the 2002 ecppm conference, in Dutch only unfortunately. But I'll post it here anyway as it is the best place to store the info.

All Dutchmen: enjoy :-) Opmerking vooraf: dit was een weekje na de conferentie geschreven i/d vorm van een email naar de STABU-collega's en m'n prof. Als er namen instaan zijn die duidelijk voor de oorspronkelijke ontvangers. Ik ga het nu niet meer herschrijven.

ECPPM in slovenie

Afgelopen week zijn Kees en ik op de Europese Conferentie voor Product- en ProcesModelleren geweest. Om een indruk ervan te geven heb ik een deel van mijn aantekeningen van de presentaties overgetypt. Als het bevalt kan ik het vaker doen, maar je mag ook gelijk op delete drukken.

Ik heb veel dingen begrijpelijk op proberen te schrijven. Aan de ene kant gebruik daarmee niet de eigenlijke "officiele" termen die op de conferentie gebruikt zijn, aan de andere kant blijft het toch nog steeds stevige materie.

Ziga Turk, organisator, openingspraatje

Er wordt vaak gezegd dat de bouwindustrie zo verspintert is zonder een grote speler die mooie standaards door kan drukken. Maar feitelijk is die er wel, namenlijk de overheid! (Later merkte iemand op dat de overheid ook weer uit meerde relatief onafhankelijke koninkrijkjes bestaat, met dus minder macht. Maar toch kan de overheid veel sturen en opdringen).

Dr. Filos, leider v/h vijfde subsidieprogramma waar het concur- en econstructgeld uit kwam.

Hij maakte twee opmerkingen over netwerken om aan te geven waarom de EU investeringen in IT, internet, communicatiestandaarden (zoals lexicon) zo belangrijk vind.

De wet van metcalfe

Het nut van een netwerk stijgt met het kwadraat van het aantal deelnemers. Dus elk extra bedrijf dat of elke persoon die eraan meedoet verhoogt het nut van het netwerk bovenproportioneel.

Minder communicatie via officiele bedrijfskanalen

En meer rechtstreeks via het netwerk. Het voorbeeld dat hij noemde dat aan de klantzijde alles via de inkoopafdeling en aan de verkoopszijde alles via de afdeling verkoop liep. Het past bij een veel meer ver-netwerkte structuur om als het nuttig is rechtstreeks te kunnen praten.

Zelf had ik al eens zoiets op het internet gelezen, maar daar stond het wat botter verwoord (maar niet noodzakerlijkerwijs verkeerd). http://www.cluetrain.org. De beginpagina is gelijk het "cluetrain manifesto", dus de samenvatting in 2 a4-tjes.

Hij voorspelde dat het zogenaamde semantic web er aan komt. Langzaam, maar zeker. Het huidige internet is een paradox van aan de ene kant een enorme stapel data waar je aan de andere kant maar mondjesmaat iets in vind. Google wordt steeds beter, maar toch. Hoe meer er bekend is over de documenten, hoe beter je er informatie uit kan halen. Google kan niets met bestekken, maar zodra google onze besteksystematiek kent... Dat is het idee van het semantic web ("internet met betekenis"). En het lexicon kan daar goed op aansluiten.

Zelf zou ik verder willen gaan door te zeggen dat het lexicon voor de bouwwereld een onmisbaar onderdeel is voor dat semantic web. (Plaatje ervan hangt trouwens al maanden op mijn whiteboard, uitleg is daar ook verkrijgbaar :-)

Godfried Augenbroe (komt aardig richting goeroe-status) (prof GeorgiaTech USA)

Zijn (eerste) praatje ging over het integreren. Het integreren van systemen/oplossingen. Een systeem bestaat uit meerdere onderdelen, zoals een besteksysteem, calculatieprogramma's, enz. En zo eens in de tien jaar komt bij onderzoekers de neiging bovendrijven om het hele gebeuren te integreren. Het idee is dan het volgende:

Elk onderdeel is met elk ander onderdeel verbonden. Bij 6 onderdelen hebben die 6!/2=360 onderlinge verbindingen. Elk extra onderdeel voegt weer meer verbindingen toe. Dat kan je op twee manieren oplossen.

1. Door er 1 groot geintegreerd programma van te maken. Het idee achter SAP en BAAN. Alleen voor de allergrootsten te betalen. Het is veel te lomp voor normale toepassingen.
2. Door 1 centraal onderdeel als spin in het web in het midden te zetten. Elk nieuw onderdeel voegt dan alleen zijn eigen verbinding toe. Maar zodra dat onderdeel vastligt kan je er er eigenlijk nooit meer wat aan veranderen zodat het gedoemd is op een gegeven moment uit te sterven. Alles staat of valt met het eerste ontwerp, dat bepaalt wat er later nog aan uitgebreid kan worden.

Maar... velen gaan uit van de theorie van "alle mogelijke verbindingen". Maar als je kijkt wat voor communicatie er in de bouw mogelijk is kom je op veel minder communicatieverbindingen uit. Kijk, dat is al gemakkelijker. En als je kijkt naar wat er in de praktijk aan communicatie plaats vind worden de verbindingen nog minder. Als dat klopt betekent dat dat de bovenstaande twee oplossingen (met hun nadelen) niet nodig zijn, je kan voor de paar overblijvende verbindingen apart iets bouwen.

Een "grijze eminentie" (die ook aanwezig was) had ooit eens tegen hem gezegd dat de onderzoekers moesten stoppen "with that pipe-dream of integrating, lets get some software done!"

Hij zei nog meer, maar het kwam er op neer om pragmatisch en eenvoudig te werk te gaan. Vat bestaande programmatuur en werkprocessen op als gegeven en plak het geheel met losse stukjes software-lijm aan elkaar.

Twee ontnuchteringen voor de onderzoekers: vraag je af of

• we ons binnen het radarbereik van de beslissingsmakers in de bouwwereld bevinden (qua lexicon let men er geloof ik op)
• de webhosters klaar zijn voor gegevensuitwisseling via het internet (merendeel nog niet)

Fruchter (USA universiteit, geeft elke student in haar sectie een laptop waarbij je op het scherm kan tekenen, het is drukgevoelig. Slurrrrp.)

Er kan al aardig wat qua informatie opslag, maar het is nog tijdrovend om iedereen de info op te laten slaan en om de informatie makkelijk bruikbaar te maken. haar tip: gebruik metaforen.

Meest stabu-gerelateerde voorbeeld: geef een hierarchie (zoals lexicon) weer als een landkaart (met vierkante vlakken, die weer verder opgedeeld, enzovoort. Kleurcodes en grootte naar gelang de hoeveelheid info die erin zit).

Thabet

Goed nieuws: er schuilt een onderzoeker in dat zoontje wat de hele nacht monsters afschiet op de PC. Sommige van die spellen kan je met meerdere mensen over het internet spelen EN ze kunnen 3d beelden aan. voila, instant programma om samen met je client eens gezellig door het niewe huis te wandelen. "Press fire to start".

Clarke

IT = verandering = jammer en rampspoed.

Dat vindt de gebruiker vaak. Denk er bij alle leuke nieuwe oplossingen dan ook aan DAT je de gebruiker goed de hele zaak (inclusief nut) uit moet leggen.

Shaaban

Classificaties zijn ervoor gemaakt om documenten te archiveren. En om ze weer terug te vinden. (rr: een of meerdere bestaande classificaties als gebruikersvriendelijke ingang voor de "koele" lexicondata gebruiken? De referenties zijn ervoor geknipt.)

Het gedrag van een gebruiker van een systeem kan je op verschillende niveaus bekijken.

Patroon

Onbewust doe je dingen op een bepaalde manier. Het is ingesleten gedrag. (Als ik iets niet weet, zoek ik het op op het internet).

Strategie

De bewust gekozen manier om het te doen. "Zoek met google".

Tactiek

De individuele keuzes. De tactische vaardigheden onderscheiden de expert van de beginner. (Hoe slim zoekt iemand op het net).

Acties

De individuele handelingen die een persoon uitvoert. Meestal is dit het enige dat je echt kan zien, tenzij je hem vraagt om hardop te denken, dan kom je ook achter de bovenliggende niveaus.

Voorbeeld voor de stabu: observeer hoe men nu bestekken maakt en hoe men er nu mee omgaat. Probeer aan de hand daarvan achter hogerliggende tactieken/strategien te komen, zodat een eventueel nieuw systeem daar zijn voordeel mee kan doen.

Rudi Stouffs (a.i.o. bouwkunde Delft)

Wil productmodellen (jargon: het lexicon model is de structuur van het lexicon) zo flexibel en intelligent mogelijk zijn. Niet mijn onderzoeksrichting, niet de richting die het lexicon op gaat, maar er zijn meerdere onderzoekers deze richting aan het opgaan. Bijna allemaal bouwkundigen die het leven v/d architect in de eerste fase willen versimpelen (of hem in die fase zoveel mogelijk data willen ontlokken).

Vraag: hoe nodig is dat in de rest van het proces als de bouwtekening al vaststaat.

Cumming (TU bouwkunde)

Benadrukte het belang van een "common ground", een gemeenschappelijk begrippenkader.

Lexicon is geknipt voor die functie. (Danwel: lexicon = een/het begrippenkader)

El-Diraby (civiel, toronto)

Eerste praatje

Ging over het berekenen van de complete kosten van constructiedelen over de gehele levensloop.

De data haalde hij uit IFC (model voor het opslaan van gegevens over een gebouw, begonnen als 3D CAD objecten uitwisselformaat). Maar dan IFC opgeslagen als ontologie in een kennis-uitwisselformaat.

Nu ben ik zelf wel een voorstander van dat kennis-uitwisselformaat omdat het een standaardmanier is van informatieopslag qua modellen. Het lexicon zou je er prima in uit kunnen drukken met als beslissende voordeel dat anderen gemakkelijker van jouw data gebruik kunnen maken en dat je ook gemakkelijker data uit andermans modellen kan halen. Als vni-uneto bijvoorbeeld hun gegevens in zo'n formaat zouden opslaan zou je gemakkelijk aan kunnen geven welke dingen aan elkaar gelijk zijn. Daar is het formaat namenlijk voor gemaakt. Zelf ga ik er verder naar kijken.

Tweede praatje

IFC is gemaakt voor gebouw-gegevens. Hij komt uit de verkeers-hoek en er zitten geen viaducten, middenbermen enz. in het IFC model. Daar proberen ze in Toronto wat aan te doen. Als het succesvol is zou het ook een betere samenwerking van CROW-data en STABU-data kunnen betekenen.

Zijn inschatting: de GWW sector is er qua informatiestandaarden nog slechter aan toe dan de B&U sector. Met uitzondering van de gasindustrie, die moeten wel absoluut correcte informatie uitwisselen!

Verder meende hij dat in dat IFC gebouwmodel al veel beschikbaar en herbruikbaar was. Hij was niet van plan zelf iets te schrijven.

Cutting-Decelle (universiteit van Evry, Frankrijk)

Ook een iso-standaardisatie project: de Process Specification Language (PSL). Om te kunnen specificeren hoe processen verlopen in de bouw. De kern van het verhaal is een ontologie (weer zo'n model zoals het lexicon er ook eentje is) met slechts 3 klassen (object, activiteit, nog_eentje), 2 functies en 7 relaties. Klein modelletje, maar ze wilden per se ook niet meer hebben. Met behulp van die gegevens kunnen ze veel beschrijven.

Een voordeel van zo'n ontologie is ook dat hij uitbreidbaar is, daar draait die ontologie-techniek om. Definitie die ze gaf: ontology = the basic terms and relations comprising the vocabulary of a topic area.

Dit klonk als een goedlopend project. Zelf wil ik daarom een kleine test uitvoeren om te kijken in hoeverre het lexicon geholpen is bij een weergave in zo'n ontologie-taal. Het lijkt 1-op-1 te passen op het eerste gezicht.

Discussie eerste avond

Godfried Augenbroe verbaasde zich erover dat in veel onderzoek kennis en processen bijna als een twee-eenheid werden opgevat. Op zich vond hij wel dat in de bouwwereld de echte kennis in de processen zit.

Verder was er een discussie over hoe je met die processen om moet gaan. De twee meningen waren:

• We kunnen processen al aardig modelleren en kunnen dus lekker aan de slag.
• We weten nog niets echt over processen en moeten ze in de practijk en in "laboratorium-omgeving" onderzoeken. We moeten nog veel leren.

Verder werd gezegt dat veel bedrijven miljoenen uitgeven om een hele stapel data bijeen te graaien en er vervolgens braafjes (en sufjes) op gaan zitten en er niets mee doen.

Celson Lima (cstb = franse TNO. Erg actief. Werkte ook in eConstruct)

Werkt nu in het eCognos project. Presenteerde de "eCognos knowledge management infrastructure". En: jahoor, alweer een ontologie. Hij verdeelde de kennis over drie niveaus:

Sectoriele kennis

De kennis die bekend is in de B&U of de GWW. De wetten, de normen.

Bedrijfskennis

De kennis binnen een bedrijf.

Projectkennis

De kennis/informatie binnen een project. Dit kan dus weer over meerdere bedrijven verdeeld zijn.

Luis Antonio

Had het over een ontologie, kennis, enzovoort, maar bedoelde een "ordinaire" classificatie (unspsc, +/- streepjescodes).

Eir

Tijdens het ontwerpproces voeg je steeds meer eigenschappen toe aan je objecten. Het doel van zijn systeem was om gaandeweg meer objecten aan een ontwerp toe te kunnen voegen en ook gaandeweg meer eigenschappen aan die objecten toe te kennen.

Via meervoudige overerving van eigenschappen kon je via een bepaald systeem bekijken welke objecten je eigenlijk onder handen hebt ("lattices"). Volgens hem moesten we niet meer object-georienteerd werken maar eigenschap-georienteerd.

Hij zag het geheel ook als een drie-deling:

Semantisch beschrijvende niveau

Lexicon-achtig. Wat is een deur, wat is een hoogte, wat is beukenhout.

Conceptuele niveau

De eigenlijke data. Een 'beukenhout'en deur met een hoogte van....

Presentatie niveau

Tekeningen, 3d afbeeldingen, enz.

Voor hem is de centrale vraag: "het" heeft deze en deze eigenschappen. Wat is het?.

Van een eigenschap-georienteerd systeem verwacht hij:

• Volledig aanpasbare ontwerpsystemen.
• Meer flexibiliteit ten behoeve van meer creativiteit.
• Betere basis voor informatieuitwisseling.

Weer een dynamisch systeem wat je voornamenlijk in de architekten-hoek van het onderzoek tegenkomt. Ik vroeg hem of dit in de latere fases van het project (als het ontwerp vaststaat) ook handig is of dat het dan een blok a/h been vormt. Wist hij het antwoord niet echt op. Het kan dus vriezen of dooien.

Fridquist (uit dezelfde hoek als de vorige spreker. Deze komt van bouwkunde Eindhoven, de vorige uit Zweden, universiteit van Lund).

Hij gaat ervanuit dat de definities van de klassen (deur, raam) vastgebakken zitten in het programma waar je mee werkt. Je creativiteit wordt daarmee ingeperkt. Wat hij eigenlijk wil is dat de ISO een basisset objecten en eigenschappen definieert waar anderen op voort kunnen bouwen. De programmatuur zou daar verder flexibel mee om moeten gaan.

Ik weet niet of hij met "ISO" ook op het lexicon doelt.

Duarte

Prachtig (want werkend!) verhaal over het ontwerpen van een woonwijk. Aan de ene kant wil je geen oostblok-achtige monotonie, aan de andere kant wil je geen ongeregeld zooitje van stijlen. Tegelijkertijd is het te veel werk om voor iedereen een huis naar eigen wensen door de architect te laten ontwerpen. Een paar types gaat nog wel, maar veel meer kan niet.

In dit onderzoek hebben ze de ontwerpen van een bekende portugese architect zoveel mogelijk in regels, formules enz. proberen te vatten op basis van een grote hoeveelheid ontwerpen die hij reeds gemaakt had. Vervolgens konden de gebruikers aan de hand van uitgebreide vragenlijsten aangeven wat ze wilden (1 of 2 verdiepingen, hoeveel personen, extra wc of niet) en zo ontstond er langzamerhand een ontwerp.

De grote test kwam toen ze na afloop van het onderzoek de resultaten aan de architect lieten zien. Tot hun vreugde zei hij dat hij het verschil eigenlijk niet kon zien tussen de door hem zelf ontworpen woningen en de uitgerekende woningen. Het lukt op deze manier dus om zowel naar de gebruikerswensen te luisteren als een uniform uitziende wijk te krijgen.

eConstruct/LexiCon

Ik laat de verhalen van david/kees/mezelf weg.

Paneldiscussie tweede dag (waaronder Kees)

Als de bouw overstapt op productmodellen en 3d modellen (en 3d cad-applicaties) zal er heel veel veranderen in de bouwpraktijk en in de manier waarop mensen hun geld verdienen. Let daarop, want zodra dit duidelijk wordt zal het voor veel weerstand zorgen. Kees: "we zitten in de informatie revolutie, er zal veel veranderen en het zal pijnlijk zijn".

Van 40 tekenaars naar 10 autocadders. Zodra het zichtbaar geld oplevert gaat het snel.

De een zegt dat je processen moet modelleren, de ander dat je producten moet modelleren. Nee, vond iemand, processen zijn eeuwenoud, ze modelleren maakt ze niet beter. Dus moeten we ons richten op het uitwisselen van informatie (voornamenlijk over producten).

We moeten niet zoveel (en teveel) beloven. Mensen worden er moe van. Als er telang gezegd wordt dat iets fantastisch is en er komt maar steeds niets uit... dan gaan mensen je negeren (en terecht).

Discussie over wat nou DE "killer application" is van al ons onderzoek. De spreadsheet was de killer app die de pc tot grote hoogtes opstootte bijvoorbeeld. Er kwamen wat suggesties, maar Kees noemde steeds dat je hele leuke applicaties kan hebben, maar zonder een standaard set definities... kom je nergens.

De gebruiker is niet geinteresseerd in al het onderzoek, die wil werkende programma's op z'n pc. We moeten als onderzoekers dus de softwarebouwers van onze zaken overtuigen.

Ook een geldige opmerking: kijken we wel voldoende naar de 97% kleine bedrijven in de bouwwereld? Zoveel onderzoek richt zich op zaken die alleen door grote bedrijven gebruikt kunnen worden vanwege de kosten of de complexiteit.

Sami Kazi (Fin)

Teveel info om op te schrijven. Hoe kan je bedrijven lekker laten samenwerken en info uit laten wisselen. Zijn conclusies waren wel:

• Applicaties moeten via het internet lopen. Punt.
• Maximaal drie keer klikken om bij je info te komen, anders loopt de gebruiker weg.

Bjork

Een documentenbeheer systeem is al lastig te verkopen, maanden vasthoudend de deur platlopen is nodig. Verwacht veel meer moeite bij het verkopen van modelleren enzo.

Gudni Gudnason (IJsland)

WebSpec, een besteksysteem, lopend op het internet, gebaseerd op het lexicon. Klonk goed. In IJsland is er nog geen systeem. Copy-paste met word.

In de bestektekst zijn de verwijzingen naar de normen/wetten enzo klikbaar gemaakt. Handig. Dit kan je met een modern internet- en xml-gebaseerd systeem. Tijd dat we opschieten met het geschikt maken van het lexicon voor bestekken! Dit zag er goed uit.

Het hele systeem draait op het internet, hoewel je delen ook lokaal zou kunnen draaien.

Toen ik hoorde dat het niet commercieel verkocht zou worden dacht ik makkelijk aan herbruikbare onderdelen te kunnen komen alleen:

• Het softwarebedrijf dat het voor hen maakte had er de hele zomer niets aan kunnen doen, dus er is nog niet heel erg veel af.
• De documentatie is helaas allemaal in het ijslands...

Oh ja, als ik documentatie rondom het lexicon maak is het dus in het engels...

Robert Amor

Praatte over UDDI, een soort gouden gids voor catalogi. Op zich werkt het wel, het is een standaard formaat met bedrijfsgegevens en productgegevens. Verschillende UDDI servers kunnen nog met elkaar de gegevens uitwisselen ook. Zet je bedrijf er een keer in en je bent theoretisch voor iedereen vindbaar.

Maar er zitten nog een paar haken en ogen aan.

• Het zoeken is gebaseerd op classificaties. "Restaurants". "Ramen en deuren". En veel verder gaat het standaard niet.
• Het zoeken wordt inefficient zodra je dingen probeert qua zoeken met parameters ("Deuren hoger dan 2 meter 20").

Op zich aardig dus, maar met beperkingen.

Cerovsek

UDDI wordt het niet. Niet veel bedrijven doen er aan mee, een van de grote drie die een database bijhielden is er al mee gestopt. Een ad-hoc methode werkt waarschijnlijk beter.

Wel eiste hij het gebruik van standaarden, standaarden, standaarden.

Kimmance

Benadrukte het belang van onafhankelijke gereedschappen. Losse programma's die je kan gebruiken zonder gelijk een hele stapel naar binnen te halen aan programma's waar je dan ook nog eens aan vast zit.

Godfried Augenbroe

Belangrijk: ze hebben onderzoek gedaan naar eConstruct en bcXML is goed genoeg voor catalogusdata!

Belangrijkste van zijn praatje was de 80/20 regel:

• In 80% van de gevallen is het genoeg om naar de eigenschappen van een object te kijken om te zien of hij voldoet aan de eisen. Een deur van 2m20 voldoet aan de vraag "een deur van meer dan 2m".
• In 20% van de gevallen heb je een deskundige (of een specialistisch programma) nodig om te bekijken of een oplossing voldoet. Het gebruikte voorbeeld was van een verlaagd plafond in een ruimte die aan bepaalde brandwerendheidseisen moest voldoen. Hoogte vanaf het eigenlijke plafond. Dat er een ventilatiekoker boven liep. Wat voor soort bestemming de ruimte heeft. Hoe groot de ruimte is. Enzovoort. Veel meer gegevens dan er als eigenschappen aan de plafondplaat hangen.

Als je dit in gedachten houdt betekent het dat je die 80% van de gevallen op de eenvoudige eConstruct-manier kan oplossen en dat de de overige 20% kan laten zitten omdat dat voer voor de experts is!