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
[email protected]
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
2
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…
3
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
4
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
5
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.
6
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
7
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
all’esplicitazione
affiancate a e non
elementi testuali,
al testo”, supporto
della conoscenza
sostitutive di
per trovare la strada
8
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
9
Esempi applicativi
 Lo studio di learning objects
 Il workflow di azioni di
conservazione del patrimoni
architettonico
10
Protégé
 Lo scenario di ambienti per lo
sviluppo e l’editing di ontologie
 Protégé-2000 (Protege 2000),

Ontolingua (Ontolingua1997),

Chimaera (Chimaera 2000).
11
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);
12
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
13
Costruzione di learning object
14
Costruzione di learning object #2
15
Costruzione di learning object #3
16
Workflow
Technic al Ris k Analy sis
Risk Analy sis
Test Planning
Ex ample of a generic
conservation strategy
Ex ample of a generic diagnostic
protocol
Data ev aluation
Prev entiv e measures
identification
Preventive measures
evaluation
Test execution
Diagnosis
Prev entiv e measures
specification
Planning
Example of a Generic Conservation action
Ev aluation
Action
On site activ ity preparation
Data Assessment
Ev aluation Procedure
Ex ample of a generic valuation
and report procedure
Ex ample of a generic on site
action
Works control
Validation and/or ex tension
On site activ ities
Report
17
Workflow:descrizioni di stato
18
Workflow applicato ad un protocollo
diagnostico
Risk Manager
The Risk Manager
helps to control the
Workflow
modelling, the
technical risk
analy sis , tools to
represent, manage,
share, report
archiv e, reuse, the
data of the
Conservation
Action
Know ledge
Base
Collaborative
Workspace
Risk agents, ex posure,
magnitudo,process of failure
Smart Set
Sharing and
updating project
data
Mobile support
Lab
Contex tual and social elements
Test procedure and support
Task Description
Risk Analy sis
Test Planning
Ex ample of a generic diagnostic
protocol
Data ev aluation and report
Test execution
Report on Ris k level, mode of
failure, performance loss
ev aluation
19
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
21
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…
22
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
23
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
24
Esempio: Express è un formalismo per
la rappresentazione dei modelli di
prodotto
25
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 26
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.
27