Appunti per l’applicazione delle ontologie al processo edilizio Università di Firenze Facoltà di Architettura Dipartimento di Tecnologie dell’Architettura e Design “Pierluigi Spadolini” Appunti per l’applicazione delle ontologie al processo edilizio Seminario Nazionale Le ontologie in campo umanistico – Archeologia Architettura e Beni Culturali Firenze 27 gennaio 2006 Marco Masera marco.masera@unifi.it

Sviluppare strumenti per il Knowledge management Obiettivi di applicazione delle ontologie al progetto di architettura/ ai processi di costruzione Sviluppare strumenti per il Knowledge management Strumenti di supporto alle metodologie di ricerca Analisi delle strutture cognitive del progetto Strumenti operativi per gestione del progetto Definizione di basi di conoscenza

Caratteristiche del campo di indagine: ontologie orientate all’azione Dominio organizzativo Progettazione/Pianificazione Processi di produzione edilizia Dominio tecnologico Domini ontologicamente “sporchi” Molteplicità di modelli Molteplicità di paradigmi Ricchezza semantica Natura linguistica della progettazione…

Questioni, temi, spunti… Tecnologia (della costruzione) / Ontologie / Modelli Knowledge Management Produzione/Condivisione/Riutilizzo nel tempo di basi di conoscenza Interoperabilità Delle organizzazioni sociali Delle applicazioni Ontologie di dominio e di sottodominio Web “semantico” come contesto operativo per organizzazioni aperte

Strumenti per la ricerca applicata nel dominio Sviluppo di un approccio sperimentale nella rappresentazione della conoscenza Strumenti per lo studio di euristiche progettuali Validazione mediante la definizione di esperimenti La condivisione di ontologie esplicite (supporto ai flussi di comunicazione nel progetto) Formalizzare procedure semi strutturate o parzialmente istanziate

Strumenti per la ricerca applicata nel dominio #2 Ontologie come strutture cognitive Reificabili Formalizzabili Verificabili con metodi empirici Obiettivo di ricerca è studiarne la stabilità, l’utilità, le ricorrenze, le invarianze ecc.

Alcune relazioni fra strumenti di indagine sulla tecnologia della costruzione Tassonomia  Vocabolario + Struttura Ontologia  Tassonomia + Vincoli e Relazioni Base di conoscenza  Ontologia + Istanze Base di conoscenza  Vocabolario + Struttura + Vincoli e Relazioni + Istanze

Delimitazione del campo operativo delle ontologie Ontologie task oriented nel dominio delle costruzioni Ontologie fungibili come elementi regolatori di reti semantiche complesse Procedure, protocolli Ontologie come paratesto (peritesto più epitesto) Ontologie “intorno al testo”, supporto all’esplicitazione della conoscenza affiancate a e non sostitutive di elementi testuali, per trovare la strada

Delimitazione del campo operativo delle ontologie #2 Ontologie come strumenti di mediazione fra tecnologia intesa come discorso e i modelli logico-matematici Connessione fra la rappresentazione di procedimenti di costruzione e grafi reticolari (reti di Petri ecc.) Ontologie per l’integrazione ed il coordinamento dei domini Ad esempio il dominio della pianificazione esteso al dominio della pianificazione temporale, esteso al dominio della pianificazione del sistema di produzione edilizio

Esempi applicativi Lo studio di learning objects Il workflow di azioni di conservazione del patrimoni architettonico

Lo scenario di ambienti per lo sviluppo e l’editing di ontologie Protégé Lo scenario di ambienti per lo sviluppo e l’editing di ontologie Protégé-2000 (Protege 2000), Ontolingua (Ontolingua1997), Chimaera (Chimaera 2000). Lo scenario di ambienti per lo sviluppo e l’editing di ontologie offre ormai una gamma consolidata di strumenti quali Protégé-2000 (Protege 2000), Ontolingua (Ontolingua1997), e Chimaera (Chimaera 2000). Da un benchmarking preliminare Protégé è apparso offrire le caratteristiche più adatte fra cui in particolare alcune: - il riferimento all’impegno duraturo nello sviluppo dello strumento e nella capacità di consolidare un gruppo di interesse scientifico fortemente interdisciplinare. - la separazione teorica e operativa fra strumenti open source e general purpose per la creazione ed il mantenimento di basi di conoscenza ed il dominio specialistico di analisi (sinergia disciplinare); - l’analogia concettuale e metodologica fra il mondo della costruzioni e lo sviluppo di ontologie in campo medico con riferimento alla definizione di protocolli diagnostici - l’obiettivo dichiarato di ridurre i colli di bottiglia nell’acquisizione della conoscenze (Hayes-Roth et al, 1983) attraverso la ridefinizione delle competenze del “knowledge engineer” nella costruzione delle basi di conoscenza. In Musen (Musen, 1988) Protégé viene definita come un’applicazione orientata a acquisire vantaggio competitivo dalla semplificazione del processo di acquisizione del processo di conoscenza.  

Protégé: caratteristiche attese impegno duraturo nello sviluppo dello strumento e nella capacità di consolidare un gruppo di interesse scientifico fortemente interdisciplinare separazione teorica e operativa fra strumenti open source e general purpose per la creazione ed il mantenimento di basi di conoscenza ed il dominio specialistico di analisi (sinergia disciplinare); Lo scenario di ambienti per lo sviluppo e l’editing di ontologie offre ormai una gamma consolidata di strumenti quali Protégé-2000 (Protege 2000), Ontolingua (Ontolingua1997), e Chimaera (Chimaera 2000). Da un benchmarking preliminare Protégé è apparso offrire le caratteristiche più adatte fra cui in particolare alcune: - il riferimento all’impegno duraturo nello sviluppo dello strumento e nella capacità di consolidare un gruppo di interesse scientifico fortemente interdisciplinare. - la separazione teorica e operativa fra strumenti open source e general purpose per la creazione ed il mantenimento di basi di conoscenza ed il dominio specialistico di analisi (sinergia disciplinare); - l’analogia concettuale e metodologica fra il mondo della costruzioni e lo sviluppo di ontologie in campo medico con riferimento alla definizione di protocolli diagnostici - l’obiettivo dichiarato di ridurre i colli di bottiglia nell’acquisizione della conoscenze (Hayes-Roth et al, 1983) attraverso la ridefinizione delle competenze del “knowledge engineer” nella costruzione delle basi di conoscenza. In Musen (Musen, 1988) Protégé viene definita come un’applicazione orientata a acquisire vantaggio competitivo dalla semplificazione del processo di acquisizione del processo di conoscenza.  

Protégé: caratteristiche attese #2 analogia concettuale e metodologica fra il mondo della costruzioni e lo sviluppo di ontologie in campo medico con riferimento alla definizione di protocolli diagnostici Protégé viene definita come un’applicazione orientata a acquisire vantaggio competitivo dalla semplificazione del processo di acquisizione del processo di conoscenza Lo scenario di ambienti per lo sviluppo e l’editing di ontologie offre ormai una gamma consolidata di strumenti quali Protégé-2000 (Protege 2000), Ontolingua (Ontolingua1997), e Chimaera (Chimaera 2000). Da un benchmarking preliminare Protégé è apparso offrire le caratteristiche più adatte fra cui in particolare alcune: - il riferimento all’impegno duraturo nello sviluppo dello strumento e nella capacità di consolidare un gruppo di interesse scientifico fortemente interdisciplinare. - la separazione teorica e operativa fra strumenti open source e general purpose per la creazione ed il mantenimento di basi di conoscenza ed il dominio specialistico di analisi (sinergia disciplinare); - l’analogia concettuale e metodologica fra il mondo della costruzioni e lo sviluppo di ontologie in campo medico con riferimento alla definizione di protocolli diagnostici - l’obiettivo dichiarato di ridurre i colli di bottiglia nell’acquisizione della conoscenze (Hayes-Roth et al, 1983) attraverso la ridefinizione delle competenze del “knowledge engineer” nella costruzione delle basi di conoscenza. In Musen (Musen, 1988) Protégé viene definita come un’applicazione orientata a acquisire vantaggio competitivo dalla semplificazione del processo di acquisizione del processo di conoscenza.  

Costruzione di learning object

Costruzione di learning object #2

Costruzione di learning object #3

Workflow

Workflow:descrizioni di stato

Workflow applicato ad un protocollo diagnostico

Complementi

Esempio di standard de facto per lo scambio dati nell’industria delle costruzioni e nell’edilizia Obiettivo: standard in alcuni segmenti di mercato e in internet per il vantaggio competitivo di alcuni prodotti Interoperabilità fra sistemi Cad o centrati su Cad. IFC ("Industry Foundation Classes") sviluppato dalla IAI ("International Alliance for Interoperability") Tentativo di accelerare il lavoro ISO attorno agli standard di dati IGES e STEP

Elementi significativi del sistema IFC in breve Standard di rappresentazione di dati grafici, architettonici, costruttivi, principalmente di oggetti 3D che possano essere scambiati fra applicazioni in competizione Logica a oggetti per CAD 3D Anche se IFC è applicato anche al Cad 2D Condivisione dati fra utenti e sviluppatori. Industria dei componenti ecc… Until fairly recently there were few CAD systems using the 3D object-based method – for example, ArchiCAD – so the applicability of IFC for inter-product exchange was limited. But now, just as the IFC development process is starting to approach completeness, more such systems are emerging, notably Nemetschek’s Allplan, Autodesk’s Architectural Desktop, and MicroStation Tri Forma. Several producers or more specialized software for the building and construction industry are also working with the IFC system. The IAI’s IFC system comprises a set of definitions of all the objects to be encountered in the building industry, and a text based structure for storing those definitions in a data file. A plain text file is used because that is the only truly universal computer data format. Then each producer of a CAD product can store their own data in whatever compact binary file format they wish to best suit their system. In addition they provide "Save As IFC" and "Read IFC" options, which map the IFC object definitions to the CAD system’s representations of those objects. Since this involves no compromise conversions such as has been common between different CAD systems, perfect data transfer is possible between any products that have IFC save and read facilities. As the development work on the basic IFC set for graphic representation slowly moves toward completion, there have been moves to extend its scope to supporting data associated with estimating and project management and similar non-graphic data, although the IFC system is essentially a graphic representation or object modeling system. Meanwhile, on August 12, 1999 another standard was proposed called aecXML. The initial work and publication of this proposal was done by Bentley Systems. In the August 12 announcement, Bentley said it was "offering the initial specification for industry review and comment and establishing an independent working group to make sure aecXML becomes an industry standard with broad, vendor-neutral support in service to all segments of the global AEC community." David Weisberg, Publisher of AEC Automation Newsletter said at the aecXML launch, "This is big, big big news. Finally! The construction industry can surely benefit from aecXML for project communications." Within a week, over 100 software companies, research institutions, standards bodies, AEC firms and other interested parties had responded to the launch of aecXML. Initially it was not clear whether this was going to be a rival system to the IAI’s. In fact, the aecXML system is designed for all the non-graphic data involved in the construction industries, and has a place alongside the IFC system, although some of the more recent moves to extend the IFC system to non-graphic data do seem to overlap. Bentley developer Bhupinder Singh, who is coordinating Bentley’s ongoing participation in the aecXML Working Group explained: "aecXML is for talking about things, not modeling them. We can use it to agree what ‘door’ means, but aecXML won’t describe doors or model them." That seems to delineate quite clearly the basic divide between aecXML and the IFC system, and also how they are mutually related. The main idea with aecXML is to not only establish some standard ways of structuring building data but also to do it so as to enable automated processing of that data as much as practicable. Much of the data within the scope of the aecXML system is currently stored as arbitrarily formatted text done in word processors, or as spreadsheets or databases. The aecXML system provides a set of keywords and named data attributes, so that all users will employ the same naming logic and grouping, and software will be able to make use of the data without it needing to be interpreted by humans and manually re-entered in each program’s required form. This is currently often the case with for example, costing systems. The name "aecXML" derives from AEC meaning "Architectural, Engineering and Construction", and XML, which is a term for a type of structured text data, standing for "eXtensible Markup Language". That in turn derived from the earlier SGML – "Structured Generalised Markup Language", which had also given rise to its now very well known sub-set, HTML or "HyperText Markup Language" – the main data mechanism of the World Wide web. Most readers of this article will know that HTML comprises text with control codes, called Tags, embedded within the text to "mark-up" how the text should be displayed. The tags are enclosed in angle-brackets to distinguish them from the text to be displayed or printed. The SGML system used the same scheme. As the Web grew and demand drove the provision of fancier display options, HTML evolved and diverged from the SGML standards. Now there is a move toward XML to accommodate more complex forms of data and to enable logical adaptation to types of data not yet specifically catered for. A web page can be defined in XML instead of HTML, but, most significantly, a web page created in XML can be queried as if it were a database; the results being presented in a browser vary depending on the nature of the query. Without XML, there needs to be a separate data base system and rather complex web-page-to-database sub-systems. Since aecXML started to establish itself, the idea has already extended to other specific fields of work, and there is now a LandXML for standardising data associated with mapping, survey and civil works. The aecXML system uses data-type tags in angle-brackets as in HTML, so that a data processing program can easily be made to search for the relevant tags and extract the required data text or numbers, confident that the correct chunks of data had been found. It should have particular usefulness in the fields of estimating, quantity surveying, and project management. Those are the areas where there appeared to be room for overlap or conflict with the IAI’s IFC work. So I was pleased to read that the two bodies were to merge. This should ensure that these two developing systems will move forward to complement each other in a very satisfactory manner. The acting director of the aecXML Working Group is Jerry Laiserin, a well-known architect, writer and information technology consultant. He is a contributing editor at Architectural Record, chairs the American Institute of Architects Center for Advanced Technology Facility Design, and serves on the Executive Board of the International Facilities Management Association Computer Applications Council. At the aecXML announcement, Laiserin said, "In the networked economy, the more you share information, the more value you create. aecXML is the key that will unlock the value of shared information throughout the global AEC marketplace." The interim standard specification for aecXML is openly available on the web in PDF format. See the links below.

Elementi significativi del sistema IFC in breve #2 Oggetti 3d: Inizialmente il campo ristretto a poche applicazioni ad es. ArchiCad Oggetti 3D: Nemetschek - Allplan, Autodesk - Architectural Desktop, MicroStation - Tri Forma “Salva come IFC”, “Apri come IFC” in plain text format Set di definizioni di tutti gli oggetti che si possono incontrare nelle costruzioni As the development work on the basic IFC set for graphic representation slowly moves toward completion, there have been moves to extend its scope to supporting data associated with estimating and project management and similar non-graphic data, although the IFC system is essentially a graphic representation or object modeling system. Meanwhile, on August 12, 1999 another standard was proposed called aecXML. The initial work and publication of this proposal was done by Bentley Systems. In the August 12 announcement, Bentley said it was "offering the initial specification for industry review and comment and establishing an independent working group to make sure aecXML becomes an industry standard with broad, vendor-neutral support in service to all segments of the global AEC community." David Weisberg, Publisher of AEC Automation Newsletter said at the aecXML launch, "This is big, big big news. Finally! The construction industry can surely benefit from aecXML for project communications." Within a week, over 100 software companies, research institutions, standards bodies, AEC firms and other interested parties had responded to the launch of aecXML. Initially it was not clear whether this was going to be a rival system to the IAI’s. In fact, the aecXML system is designed for all the non-graphic data involved in the construction industries, and has a place alongside the IFC system, although some of the more recent moves to extend the IFC system to non-graphic data do seem to overlap. Bentley developer Bhupinder Singh, who is coordinating Bentley’s ongoing participation in the aecXML Working Group explained: "aecXML is for talking about things, not modeling them. We can use it to agree what ‘door’ means, but aecXML won’t describe doors or model them." That seems to delineate quite clearly the basic divide between aecXML and the IFC system, and also how they are mutually related. The main idea with aecXML is to not only establish some standard ways of structuring building data but also to do it so as to enable automated processing of that data as much as practicable. Much of the data within the scope of the aecXML system is currently stored as arbitrarily formatted text done in word processors, or as spreadsheets or databases. The aecXML system provides a set of keywords and named data attributes, so that all users will employ the same naming logic and grouping, and software will be able to make use of the data without it needing to be interpreted by humans and manually re-entered in each program’s required form. This is currently often the case with for example, costing systems. The name "aecXML" derives from AEC meaning "Architectural, Engineering and Construction", and XML, which is a term for a type of structured text data, standing for "eXtensible Markup Language". That in turn derived from the earlier SGML – "Structured Generalised Markup Language", which had also given rise to its now very well known sub-set, HTML or "HyperText Markup Language" – the main data mechanism of the World Wide web. Most readers of this article will know that HTML comprises text with control codes, called Tags, embedded within the text to "mark-up" how the text should be displayed. The tags are enclosed in angle-brackets to distinguish them from the text to be displayed or printed. The SGML system used the same scheme. As the Web grew and demand drove the provision of fancier display options, HTML evolved and diverged from the SGML standards. Now there is a move toward XML to accommodate more complex forms of data and to enable logical adaptation to types of data not yet specifically catered for. A web page can be defined in XML instead of HTML, but, most significantly, a web page created in XML can be queried as if it were a database; the results being presented in a browser vary depending on the nature of the query. Without XML, there needs to be a separate data base system and rather complex web-page-to-database sub-systems. Since aecXML started to establish itself, the idea has already extended to other specific fields of work, and there is now a LandXML for standardising data associated with mapping, survey and civil works. The aecXML system uses data-type tags in angle-brackets as in HTML, so that a data processing program can easily be made to search for the relevant tags and extract the required data text or numbers, confident that the correct chunks of data had been found. It should have particular usefulness in the fields of estimating, quantity surveying, and project management. Those are the areas where there appeared to be room for overlap or conflict with the IAI’s IFC work. So I was pleased to read that the two bodies were to merge. This should ensure that these two developing systems will move forward to complement each other in a very satisfactory manner. The acting director of the aecXML Working Group is Jerry Laiserin, a well-known architect, writer and information technology consultant. He is a contributing editor at Architectural Record, chairs the American Institute of Architects Center for Advanced Technology Facility Design, and serves on the Executive Board of the International Facilities Management Association Computer Applications Council. At the aecXML announcement, Laiserin said, "In the networked economy, the more you share information, the more value you create. aecXML is the key that will unlock the value of shared information throughout the global AEC marketplace." The interim standard specification for aecXML is openly available on the web in PDF format. See the links below.

Elementi significativi del sistema IFC in breve #3 Elementi complementari: dati non grafici estensione alle stime, al project management Oggetti 3D: Nemetschek - Allplan, Autodesk - Architectural Desktop, MicroStation - Tri Forma “Salva come IFC”, “Apri come IFC” in plain text format Set di definizioni di tutti gli oggetti che si possono incontrare nelle costruzioni IFC è essenzialmente un sistema di modellazione di oggetti grafici Meanwhile, on August 12, 1999 another standard was proposed called aecXML. The initial work and publication of this proposal was done by Bentley Systems. In the August 12 announcement, Bentley said it was "offering the initial specification for industry review and comment and establishing an independent working group to make sure aecXML becomes an industry standard with broad, vendor-neutral support in service to all segments of the global AEC community." David Weisberg, Publisher of AEC Automation Newsletter said at the aecXML launch, "This is big, big big news. Finally! The construction industry can surely benefit from aecXML for project communications." Within a week, over 100 software companies, research institutions, standards bodies, AEC firms and other interested parties had responded to the launch of aecXML. Initially it was not clear whether this was going to be a rival system to the IAI’s. In fact, the aecXML system is designed for all the non-graphic data involved in the construction industries, and has a place alongside the IFC system, although some of the more recent moves to extend the IFC system to non-graphic data do seem to overlap. Bentley developer Bhupinder Singh, who is coordinating Bentley’s ongoing participation in the aecXML Working Group explained: "aecXML is for talking about things, not modeling them. We can use it to agree what ‘door’ means, but aecXML won’t describe doors or model them." That seems to delineate quite clearly the basic divide between aecXML and the IFC system, and also how they are mutually related. The main idea with aecXML is to not only establish some standard ways of structuring building data but also to do it so as to enable automated processing of that data as much as practicable. Much of the data within the scope of the aecXML system is currently stored as arbitrarily formatted text done in word processors, or as spreadsheets or databases. The aecXML system provides a set of keywords and named data attributes, so that all users will employ the same naming logic and grouping, and software will be able to make use of the data without it needing to be interpreted by humans and manually re-entered in each program’s required form. This is currently often the case with for example, costing systems. The name "aecXML" derives from AEC meaning "Architectural, Engineering and Construction", and XML, which is a term for a type of structured text data, standing for "eXtensible Markup Language". That in turn derived from the earlier SGML – "Structured Generalised Markup Language", which had also given rise to its now very well known sub-set, HTML or "HyperText Markup Language" – the main data mechanism of the World Wide web. Most readers of this article will know that HTML comprises text with control codes, called Tags, embedded within the text to "mark-up" how the text should be displayed. The tags are enclosed in angle-brackets to distinguish them from the text to be displayed or printed. The SGML system used the same scheme. As the Web grew and demand drove the provision of fancier display options, HTML evolved and diverged from the SGML standards. Now there is a move toward XML to accommodate more complex forms of data and to enable logical adaptation to types of data not yet specifically catered for. A web page can be defined in XML instead of HTML, but, most significantly, a web page created in XML can be queried as if it were a database; the results being presented in a browser vary depending on the nature of the query. Without XML, there needs to be a separate data base system and rather complex web-page-to-database sub-systems. Since aecXML started to establish itself, the idea has already extended to other specific fields of work, and there is now a LandXML for standardising data associated with mapping, survey and civil works. The aecXML system uses data-type tags in angle-brackets as in HTML, so that a data processing program can easily be made to search for the relevant tags and extract the required data text or numbers, confident that the correct chunks of data had been found. It should have particular usefulness in the fields of estimating, quantity surveying, and project management. Those are the areas where there appeared to be room for overlap or conflict with the IAI’s IFC work. So I was pleased to read that the two bodies were to merge. This should ensure that these two developing systems will move forward to complement each other in a very satisfactory manner. The acting director of the aecXML Working Group is Jerry Laiserin, a well-known architect, writer and information technology consultant. He is a contributing editor at Architectural Record, chairs the American Institute of Architects Center for Advanced Technology Facility Design, and serves on the Executive Board of the International Facilities Management Association Computer Applications Council. At the aecXML announcement, Laiserin said, "In the networked economy, the more you share information, the more value you create. aecXML is the key that will unlock the value of shared information throughout the global AEC marketplace." The interim standard specification for aecXML is openly available on the web in PDF format. See the links below.

Esempio: Express è un formalismo per la rappresentazione dei modelli di prodotto

aecXML – (architecural, engineering and construction + extensible markup language) Agosto 1999 comunicato della Bentley:”… offering the initial specification for industry review and comment and establishing an independent working group to make sure aecXML becomes an industry standard with broad, vendor-neutral support in service to all segments of the global AEC community." aecXML è progettato per tutte le applicazioni non grafiche applicabili all’industria delle costruzioni Le estensioni di IFC proseguono in questa direzione sovrapponendosi all’iniziativa della Bentley Oggetti 3D: Nemetschek - Allplan, Autodesk - Architectural Desktop, MicroStation - Tri Forma “Salva come IFC”, “Apri come IFC” in plain text format Set di definizioni di tutti gli oggetti che si possono incontrare nelle costruzioni IFC è essenzialmente un sistema di modellazione di oggetti grafici Bentley developer Bhupinder Singh, who is coordinating Bentley’s ongoing participation in the aecXML Working Group explained: "aecXML is for talking about things, not modeling them. We can use it to agree what ‘door’ means, but aecXML won’t describe doors or model them." That seems to delineate quite clearly the basic divide between aecXML and the IFC system, and also how they are mutually related. The main idea with aecXML is to not only establish some standard ways of structuring building data but also to do it so as to enable automated processing of that data as much as practicable. Much of the data within the scope of the aecXML system is currently stored as arbitrarily formatted text done in word processors, or as spreadsheets or databases. The aecXML system provides a set of keywords and named data attributes, so that all users will employ the same naming logic and grouping, and software will be able to make use of the data without it needing to be interpreted by humans and manually re-entered in each program’s required form. This is currently often the case with for example, costing systems. The name "aecXML" derives from AEC meaning "Architectural, Engineering and Construction", and XML, which is a term for a type of structured text data, standing for "eXtensible Markup Language". That in turn derived from the earlier SGML – "Structured Generalised Markup Language", which had also given rise to its now very well known sub-set, HTML or "HyperText Markup Language" – the main data mechanism of the World Wide web. Most readers of this article will know that HTML comprises text with control codes, called Tags, embedded within the text to "mark-up" how the text should be displayed. The tags are enclosed in angle-brackets to distinguish them from the text to be displayed or printed. The SGML system used the same scheme. As the Web grew and demand drove the provision of fancier display options, HTML evolved and diverged from the SGML standards. Now there is a move toward XML to accommodate more complex forms of data and to enable logical adaptation to types of data not yet specifically catered for. A web page can be defined in XML instead of HTML, but, most significantly, a web page created in XML can be queried as if it were a database; the results being presented in a browser vary depending on the nature of the query. Without XML, there needs to be a separate data base system and rather complex web-page-to-database sub-systems. Since aecXML started to establish itself, the idea has already extended to other specific fields of work, and there is now a LandXML for standardising data associated with mapping, survey and civil works. The aecXML system uses data-type tags in angle-brackets as in HTML, so that a data processing program can easily be made to search for the relevant tags and extract the required data text or numbers, confident that the correct chunks of data had been found. It should have particular usefulness in the fields of estimating, quantity surveying, and project management. Those are the areas where there appeared to be room for overlap or conflict with the IAI’s IFC work. So I was pleased to read that the two bodies were to merge. This should ensure that these two developing systems will move forward to complement each other in a very satisfactory manner. The acting director of the aecXML Working Group is Jerry Laiserin, a well-known architect, writer and information technology consultant. He is a contributing editor at Architectural Record, chairs the American Institute of Architects Center for Advanced Technology Facility Design, and serves on the Executive Board of the International Facilities Management Association Computer Applications Council. At the aecXML announcement, Laiserin said, "In the networked economy, the more you share information, the more value you create. aecXML is the key that will unlock the value of shared information throughout the global AEC marketplace." The interim standard specification for aecXML is openly available on the web in PDF format. See the links below.

aecXML – Bentley System #2 "aecXML is for talking about things, not modeling them. We can use it to agree what ‘door’ means, but aecXML won’t describe doors or model them." Questa affermazione sembra delineare abbastanza chiaramente la distinzione fra aecXML e sistema IFC L’idea chiave in aecXML è quella di rendere più praticabile l’automazione nel processare i dati aecXML fornisce parole chiave e nomina gli attributi dei dati, favorendone l’interpretazione da parte dei programmi software saltando il passaggio dell’interpretazione umana e della re implementazione nei programmi. Most readers of this article will know that HTML comprises text with control codes, called Tags, embedded within the text to "mark-up" how the text should be displayed. The tags are enclosed in angle-brackets to distinguish them from the text to be displayed or printed. The SGML system used the same scheme. As the Web grew and demand drove the provision of fancier display options, HTML evolved and diverged from the SGML standards. Now there is a move toward XML to accommodate more complex forms of data and to enable logical adaptation to types of data not yet specifically catered for. A web page can be defined in XML instead of HTML, but, most significantly, a web page created in XML can be queried as if it were a database; the results being presented in a browser vary depending on the nature of the query. Without XML, there needs to be a separate data base system and rather complex web-page-to-database sub-systems. Since aecXML started to establish itself, the idea has already extended to other specific fields of work, and there is now a LandXML for standardising data associated with mapping, survey and civil works. The aecXML system uses data-type tags in angle-brackets as in HTML, so that a data processing program can easily be made to search for the relevant tags and extract the required data text or numbers, confident that the correct chunks of data had been found. It should have particular usefulness in the fields of estimating, quantity surveying, and project management. Those are the areas where there appeared to be room for overlap or conflict with the IAI’s IFC work. So I was pleased to read that the two bodies were to merge. This should ensure that these two developing systems will move forward to complement each other in a very satisfactory manner. The acting director of the aecXML Working Group is Jerry Laiserin, a well-known architect, writer and information technology consultant. He is a contributing editor at Architectural Record, chairs the American Institute of Architects Center for Advanced Technology Facility Design, and serves on the Executive Board of the International Facilities Management Association Computer Applications Council. At the aecXML announcement, Laiserin said, "In the networked economy, the more you share information, the more value you create. aecXML is the key that will unlock the value of shared information throughout the global AEC marketplace." The interim standard specification for aecXML is openly available on the web in PDF format. See the links below.