1 Introduction
Internet of Things (IoT) consist of scattered devices that exchange data over local networks and the web, expanding the field of Building Information Modeling (BIM) as we know it. The Semantic Web (SW) and Linked Data (LD) paradigms allow us to connect BIMs with IoT concepts semantically and functionally. The addition of Artificial Intelligence (AI) agents capable of communicating and following individual goals pave the way to automation, smart construction, and digital twins. The digital project model and the model exchange formats have been subjects of research and standardization over the past decades, with the Industry Foundation Classes (IFC) schema being at the core of interoperability and fostering project stakeholder collaboration (
Laakso and Kiviniemi, 2012). However, this approach is often insufficient when formalizing other complex socio–technical systems, which need to include hardware (e.g., devices that host digital models), software (e.g., collaborative tools that modify models and help users collaborate), people (e.g., architects, planning engineers), and broader community aspects (e.g., the way people collaborate within specific technological contexts).
The research presented in this paper is part of the 4DCollab project (
Boje et al., 2019; 4DCollab, 2020). This international research project aims to deliver a novel, holistic, and collaborative 4D modeling experience for decision making under a user-centric approach (
ISO, 2019). The scope of this article is narrowed to ontology the representation of a Synchronous Collaboration Session (SCS) with collocated collective decision making. The representation is designed within a context of an SCS with 4D BIM uses (use-cases) and implementation of a digital multiuser touch table for project information visualization and interactions. During an SCS, participants (i.e., the users) must have natural, but domain-customized interactions (
Kubicki et al., 2019) with the digital project documentation. As part of the same project, previously conducted experiments with construction industry professionals
(Bolshakova et al., 2017) and students (
Bolshakova et al., 2018) have revealed two major functional requirements for the digital support setting: 1) a domain-adapted, user-centered interface, and 2) accessibility of the project data at the collaborative session level, and its integration into the overall project workflow.
This article offers an extended version of
Boje et al. (2019) and focuses in particular on showcasing the 4DCollab ontology model to: 1) provide an ontological representation of an SCS for decision making with 4D BIM-based planning; and 2) facilitate the implementation of a 4D-based collaboration support prototype.
In terms of structure, Section 2 presents 4D BIM with its applications in construction, semantics and the use of knowledge-based models in the recent research landscape. Section 3 describes the ontology engineering process and the main steps of the research undertaken. Section 4 analyses the related ontology and schema models by discussing their limitations. Section 5 describes the main proposition of the 4DCollab ontology model by illustrating its main features, which range from SCS concepts to 4D modeling and data properties, and provides several examples on querying to demonstrate 4DCollab ontology usage. Section 6 highlights the limitations of the study, followed by the conclusions and future work.
2 Background research
2.1 Digital project development and the 4D BIM concept
The use of BIM is implemented during the entire project development cycle. The implementation of digital models and management methods begins at the design stage of a project, continues during the construction stage, and later supports the facility management of the delivered project (
Gao and Fischer, 2008;
Kreider and Messner, 2013). The digital information complexity increases throughout the project lifecycle (
Wood et al., 2014). Consequently, it reaches its apex at the preconstruction and construction stages, where stakeholders converge their BIM models specifically to their domain of expertise. This convergence makes a shared BIM model the core of project data exchanges, thereby improving coordination, collaboration, and decision making (
National Building Specification, 2014;
Ghaffarianhoseini et al., 2017).
In addition, a shared BIM model allows the efficient management of a complex project information within different
nD dimensions of BIM (
Lee et al., 2005). A 4D model with specific semantics is created when the virtual 3D model of a project is enriched with “time”-related data. Moreover, the 4D model is a simulation of a process (
McKinney et al., 1996). 4D modeling mostly occurs at the pre-construction and construction stages (
Hu and Zhang, 2011;
Boton et al., 2015) when the connection between the 3D BIM and the time management information is merged (
Ding et al., 2014).
As a representation of the construction site, the 4D model may be applied together with other BIM uses. For now, project visualization is the main 4D BIM use that is strongly associated with planning sequencing and clash detection.
Guerriero et al. (2017) proposed 4D BIM uses by focusing on assistance to decision making, including scheduling, clash detection, safety management, site lay-out and environment management, site monitoring and constructability management. As digital project information supports decision-making, these 4D BIM uses may also be referenced during the project development (
Bolshakova et al., 2018), where they can be present in various formats and with different levels of 4D semantics (
Boton et al., 2013).
2.2 Data environment of SCS
An SCS setting assumes that project stakeholders (users) meet around a digital table equipped with a Natural User Interface (NUI), which is represented by a multi-touch collaborative device hardware and software for collaborative decision making (
Immersion, 2020). Although NUIs provide accessible model manipulation and short learning times
(Steinberg, 2012), the underlying model data (i.e., the importing of digital project documents from heterogeneous sources) that users require during such meetings must be defined. However, these data sources are not semantically connected, thereby hindering the collaboration and digital continuity of the project documentation.
Usually, the data environment of an SCS on a construction project is heterogeneous because it integrates data from multiple disciplines that come in different file formats and specialized tools (
Lee et al., 2015). Current industry practices rely on IFC, which offers some degree of interoperability for common data exchanges (
Laakso and Kiviniemi, 2012). However, the use of IFC to work with scheduling information or other relevant construction documentation (external model referencing) is not a common practice. During SCSs, the 4D simulation encompasses a 3D geometry and the scheduled activities, which should be merged and reintegrated into the development process (
Porkka and Kähkönen, 2007;
Moon et al., 2014). Additionally, external documentation related to the decision-making processes (e.g., site scans, photos, change orders, etc.) should be incorporated (
Turkan et al., 2012), thereby making the data prospect extremely diverse and highlighting a need for an adaptive 4D model visualization and manipulation (
Boton et al., 2011;
2013). Finally, the highly semantic model links need to persist outside the collaborative meeting process to facilitate model change orders and thus remain integrated into the iterative design process (
Kassem et al., 2015;
Oh et al., 2015). The collaboration support should allow a semantically rich, knowledge-driven environment that would place model data in the core of session interactions.
2.3 Semantics in a web-based digital era
The IFC schema can be used to represent almost every aspect of design and construction in detail, ranging from basic geometric representations of objects to nD models. In the context of BIM models, semantics lie at the core of all its objects. In fact, every object inside the model symbolizes a real-life asset that may eventually become a building component. The simplest example of these semantics is the properties that are attached to the programmatic objects: “Wall: length = 3000 mm” or “Task: duration = 3 hours”. High-level semantic documents (e.g., BIMs) are preferred to low-level semantic documents (e.g., text documents) because they enable faster processing and automation, thus facilitating better overall digital interoperability. As such, IFC has become a widely used industry standard for transferring digital documentation between project stakeholders because of its sheer size and comprehensiveness within the construction domain. However, the construction industry relies heavily on document-based transactions, exchanging model data over the web using digital documents in various legacy formats.
Linked Data refers to a concept developed under the efforts of the World Wide Web Consortium (W3C), which enables the intelligent use of data across unstructured Internet resources. With improved levels of semantics, LD represents a powerful tool toward increased “meaning” of data on the SW. The Resource Description Framework (RDF) and the Web Ontology Language (OWL) are the building blocks of the SW that are complemented by additional frameworks and tools, all aimed at constructing SW applications via “the Semantic Web Stack” (
Horrocks et al., 2005).
Unlike IFC, which is at its core structured model data, an OWL format adds more expressivity to the data by introducing higher semantics. In general terms, ontologies define “things” that exist, whereas semantics characterize and describe the relationships between these things. OWL refers to a machine-interpretable format that offers the additional inclusion of logic rules and the promise of expansion to any nearby domain over the SW. The emergence of IfcOwl (
Beetz et al., 2009) has several implementations within the SW context (
Pauwels et al., 2017). The ontology representation of the BIM not only bypasses the interoperability problem, but also offers a robust foundation for storing and linking data on the web (
Venugopal et al., 2015). Most importantly, it allows a more comprehensive conceptual and consequently digital representation of real-world things from simple semantics to knowledge.
2.4 Knowledge bases for collaboration sessions
The use of ontologies in the construction sector has gradually increased (
Abanda et al., 2013;
Pauwels et al., 2017), with application domains in cost estimation (
Niknam and Karshenas, 2015), risks analysis (
Fidan et al., 2011) and energy performance (
Tomašević et al., 2015). Furthermore, the current research landscape on using ontologies in conjunction with 4D BIM uses is extremely limited.
Zhang et al. (2015) presented a safety management ontology with knowledge rules, but not targeted at 4D modeling.
Niknam and Karshenas (2016)represented the BIM and a schedule model by using a simple ontology, but without considering existing industry standards such as the IFC. Although the IFC schema already includes sophisticated concepts for time and scheduling, it lacks concepts related to inter-user collaboration and their decision-making processes. Additionally, the use of the IFC schema within the 4D domain is currently limited to research (
Hamledari et al., 2017) with a vast majority of concepts not implemented nor used by industry practitioners.
Nonetheless, significant progress has been made to integrate the SW in parallel fields, such as IoT (
Sezer et al., 2016) or smart cities (
Howell and Rezgui, 2018). These recent developments in adjacent research fields advocate the use of knowledge-based environments that use SW resources. A knowledge base would be well positioned to offer a robust semantic knowledge data store that can be used as a resource to support SCS in analyzing, designing and automating the processes involved around 4D BIM (Fig. 1).
3 Methodology
On the subject of ontology design, also termed as “knowledge engineering”,
Noy and McGuinness (2001) argued that no one correct way of defining an ontology exists, and this iterative process usually depends on the knowledge domain and the scope of the ontology. The starting principle is to be able to represent knowledge about the application domain—in this case the subject of 4D BIM assisted SCSs. The use of “competency questions” serves as a formal way of assessing whether an ontology meets certain objectives and is capable of providing an answer to the problem it is applied to.
A rigorous experiment focused methodology was employed on the basis of the observations from several SCS and on the feedback of the industry professionals involved. The initial interactions between users and 4D models were formalized by following five successive observations of real-life project meetings that consist of up to four collaborators (e.g., clients, architects, planners, and structural engineers). To ensure that validated concepts from adjacent knowledge domains are reused, existing schema and ontology models were also analyzed (Section 4). The ontology itself (Section 5) was set to follow certain objectives to focus on its use (Fig. 2). The first two objectives target things that are virtual (e.g., the building models and documents) and real (e.g., the actors, the devices they use), thereby capturing an environment in which people use the 4D model to plan and decide collaboratively. The third objective is more concerned with providing an intelligent, knowledge-driven environment where the context of each session is captured for future reference and analysis, thereby adding value to the knowledge management process. The final objective is to test and validate the ontology, which would further ensure its efficacy and completeness (Section 5.4).
The steps taken toward achieving these objectives are presented as follows:
(1) Identification of SCS concepts: On the basis of previous research (
Boton et al., 2013;
Bolshakova et al., 2017;
2018), several features of interest were identified. These features are used to conceptualize the things from the collaborative environment perspective formally;
(2) Identification of 4D BIM concepts: Based on the analysis of the structures and semantics of ontological models within the domain of project planning, common concepts are outlined and reused to model the 4D BIM perspective;
(3) Creation of 4DCollab main classes: On the basis of the previous steps, an initial vocabulary of concepts was outlined. These concepts constitute the main 4DCollab ontology classes, which are used to describe the knowledge domain;
(4) Creation of object properties: The first step toward defining the model semantics is by expressing the abstract relationships between the classes;
(5) Creation of data properties: Similar to the above step, additional semantics about the required data are modeled. Any properties that are relevant for eventual data processing are identified and included;
(6) Implementation of a knowledge base: The process by which ontology facts (termed the Tbox) are linked to actual resource instance graphs (termed Abox). This process consists of placing the 4DCollab ontology graph (in OWL) with resources graphs (in RDF) in a triple store to test the validity of the represented model by subjecting it to querying and reasoning;
(7) Testing via SPARQL queries: Several queries were devised on the basis of competency questions to evaluate whether the knowledge database can provide logically correct and adequate answers. This step represents the first approach toward ontology validation.
4 Analysis of existing concepts
Several existing schemas and ontologies relevant to the BIM, collaboration, and project management domains were surveyed as part of the initial methodology steps (Steps 1 and 2 in Fig. 2). These existing schemas and ontologies are listed in Table 1 along with their respective concept fields under the scope of the 4DCollab ontology engineering process: Description of geometry, time, scheduling, collaboration, resources (documents, costs, labor, materials, etc.), and Level of Detail/Development (LOD).
The majority of schema models outlined in Table 1 are heavily focused on specific domains and have relatively small scopes. Therefore, they are only relevant to one or two concept fields. The PROMONT ontology, which could be re-used to describe relationships between tasks and time management, represents collaboration and project management concepts generically. However, its remoteness limits its usability.
Models that deal with collaboration concepts describe things too generically, thereby limiting their usability or value in the specific context of 4D BIM SCS. The collaborative meeting workflow was also a field of interest when analyzing existing concepts. Guidance on 4D BIM modeling (
CIC, 2011) describes the collaborative process as combining the geometry with scheduling information (3D+scheduling), but not in a synchronous context. Additionally, various artifacts are in use during an SCS, and these artifacts can be imported to the digital table in an ad hoc manner (
Mehrbod et al., 2019). Therefore, one of the aims of the 4DCollab ontology is to provide the necessary relationships between these artifacts, the BIM, the actors, and any other relevant ad hoc external resources which are required in the decision-making process. The Microsoft Project schema was also considered, because it is a typical tool used in project management in several fields. However, it lacks an ontology level description and representation.
Due to its sheer size, the IFC schema stands out, covering most of the required concept fields. However, the complexity and heavy structure of the IFC schema and consequently IfcOwl make it a less than optimal ontology to be used in practice when traversing the graph structure, and even less so when applying reasoning. This has been a subject of research in its own right. As a response, the scientific community within the construction industry has come up with several smaller and more modular ontologies, such as Building Topology ontology (BOT) or Ontology for Property Management (OPM), most of which are aligned to and used in conjunction with IfcOwl. However, none of these novel ontology models include within their scope the synchronous collaboration between users and their interactions with various digital documents and artifacts, which were outlined as part of this research in
Bolshakova et al. (2018).
From a technical and implementation perspective, the IFC schema version also needs to be considered. Although they reuse a large percentage of the same concepts, the 10-year difference of development between IFC2×3 and IFC4 has caused some significant changes, especially at the instanced (non-abstract) classes’ level, meaning that every IFC version is effectively another ontology. An example of this when creating planning tasks is highlighted in Fig. 3. On a syntax level, in IFC2×3 the object that connects the IfcTask to the IfcWorkSchedule is IfcRelAssignsTasks, which also references the actual task time for the same IfcTask, using the concept of IfcScheduleTimeControl (subclass of IfcControl). This means that the planning starts by looking at the calendar, then finding each task, and subsequently its related IfcProduct (3D objects), IfcResource (e.g., costs, labor), and IfcProcess (e.g., events, tasks). For IFC4 however, IfcTask is less constrained to IfcControl relationships, and its conceptualization of time is more condensed, thereby effectively removing intermediary classes, arguably making the model more concise from an implementation perspective.
Regardless of the schema version, one can deduce if a BIM is a 4D BIM by identifying whether the model includes instances of IfcTask. These instances should be connected to other objects via the IfcRelAssignToProcess relationship or more specifically to geometric building components via the IfcRelAssignsToProduct relationship. As such, a significant number of existing classes from the IFC schemas are reused to integrate with the specific utilization case of the 4D BIM under the current research context.
5 4DCollab ontology
The conjunction between the project aims and the ontology objectives were used to design an initial 4DCollab ontology. Its main classes are shown in Fig. 4, following several competency questions which were used to guide the scope of the ontology logically.
5.1 4D model
A pivotal element in the meeting is the 4D model itself and its dependent digital objects and documents which are utilized by the users around the table. The primary competency questions posed were:
“What does the 4D model have to provide during a collaborative meeting?”
The Model class abstracts the interactions between 4D modeling objects and documents that are related to SCS. The difference between Model and Document is that the latter represents a static file, whereas the Model and its ModelObject represent the fully semantic BIM objects that can be dynamically loaded and manipulated during the meeting using the knowledge graphs underneath. Thus, each imported Document on its own provides a model view with limited semantics, but when used in conjunction with the 4DCollab ontology classes, the overall model scope is expanded, and its semantics are enriched. This is also reflected in Fig. 4 by including the imported (external) IFC classes.
The ModelObject class is used to refer to model objects from planning to 2D/3D/4D generically, together with their parametric properties. For more specific cases, some subclasses were constructed to refer to several collection types of objects encountered within the Model. Physical-Object conceptualizes all the elements within the BIM that have a physical representation in reality, thereby including the entire set of IfcBuildingElement class within IfcOwl. TemporalObject refers to concepts that are related to time and therefore used to describe the scheduling of the model, including in this case IfcOwl classes, such as IfcEvent and IfcTask with all their attached components. Grouping-Object refers to the abstract collections of objects (similar to IfcGroup) and set to also include building segmentation, which consists of IfcSpatialStructure. It acts as a container of other objects, being used to refer to specific zones, areas, spaces, and levels within a building, specific groups of scheduling tasks or a hybrid combination of objects. This phenomenon ensures dynamic grouping definitions according to user needs.
“What can be considered a 4D model object?”
The ability to identify whether a BIM was indeed a 4D model is important. Implicitly, this approach can be done by identifying objects that are defined at a 4D level, which indicates that these objects have a geometric representation (2D or 3D) with additional planning information connected to it. Therefore, the Object4D class implements this condition. An Object4D corresponds to a ModelObject that has an IfcTask and an IfcProduct (explicitly defined as an object with 2D/3D geometrical representation within the IFC schema). Object4D is effectively very similar to IfcRelAssignsToProcess or IfcRelAssignsToProduct (Fig. 3). The difference is that Object4D formally constructs an object type that needs to have one IfcTask and at least one IfcProduct, whereas IfcRelAssignsToProcess is applied at a higher and more generic level. Additionally, the latest IFC schemas restrict the use of IfcRelAssignsToProduct to represent the connection between one IfcProduct and multiple IfcProcesses (e.g., IfcTask), thereby restricting the capability of grouping the building components from a planning perspective.
5.2 Attaching the data properties
To align with the third methodology objective in Section 3, the 4DCollab ontology stores all relevant data about the model and the session via data object properties (green boxes in Fig. 4
). This defaults to things that can be measured or used to gather data such as user identity, session start dates, or imported Documents (file names, locations, sizes). At the model level, the data properties depend on the imported IFC classes. However, the presence of Model-related data will be managed using the LOD class. Its implementation relies on reasoning rules to consistently check the presence/absence of data. In return, the monitoring of the model changes according to the meeting objectives and results creates a connection between LOD progressions not just at a 3D level, but at a 4D BIM level through the use of existing literature frameworks (
Butkovic et al., 2019). These implementations potentially enable the capability of knowledge storage, benefit future knowledge retrieval, and provide a means to use AI and data analytics to further optimize and replicate design decisions within the context of 4D planning.
5.3 Implementing a knowledge graph database
This section addresses the final objective and last two steps of the methodology in Section 3, which includes the implementation of a knowledge base and subsequently testing it by subjecting the included ontologies to queries.
The dotNetRDF library (dotNetRDF, 2019) was used to simulate an in-memory knowledge base within a system under development. In the context of using ontologies, a knowledge base usually consists of a Tbox and an Abox. The Tbox model consists of the schema model, the 4DCollab ontology, and its dependencies, such as IfcOwl (IFC4 version), which states the model facts, such as existing concepts and their interactions. The Abox consists of data and statements about the ontology individuals (instance data), which are stored in separate RDF graph that have to be Tbox model compliant. Thus, a mock resource graph of a typical Session was created programmatically, and a sample IFC4 building model was converted into an IfcOwl resource graph using
Pauwels et al. (2016)’s conversion tool. The data they provide would contextualize under the applied ontology models, thereby allowing the knowledge graph database to be used for reasoning and basic querying.
5.4 Querying with SPARQL
SPARQL is the standard SW query language used to query RDF graphs by pattern matching triples (subject→predicate→object). Each SPARQL query during live SCS would represent the needs of the collaborative device end-users. The model data stored within the ontology graph database would be queried ad hoc to satisfy the session information requirements. Simpler questions posed are limited by the availability of information, which should be present and valid, whereas complex questions would require the implementation of reasoning rules.
Several sample selection queries are listed in Table 2, with two working examples shown in Figs. 5 and 6. Each query is described in Table 2 by using natural language questions and by outlying their scope during project meetings.
6 Discussion
The ontological representation of a complex socio-technical system was outlined throughout the previous sections of this article. The ontology engineering process, as outlined in the methodology (Section 3), is iterative by nature. As such, the structure and syntax of the 4DCollab ontology is expected to change after successive testing. We argue that such changes need to be considered through three different perspectives.
6.1 User experience perspective
The 4DCollab ontology is centered on the real-world collaborative environment, thereby giving it a very focused modeling scope. The ontological expression of these semantics enable the seamless integration between actors and their collaboration resources from the real and digital worlds. The inclusion of linked data over the SW is implicit, where users are identified by their e-mails for example. Although the specific types of Interactions that users make have been identified (i.e., Visualization, Annotation, and Modification), the specific relationships between Users and ModelObjects still needs to be formalised. These relationships would need to consider the various levels of granularity on how the model is presented to the user by space (i.e., location, proximity to other objects), time (i.e., referring to planning tasks or previous versions of objects in time), discussion objectives (cost items, site equipment, etc.) and scope. The ability of the user to traverse the model data should resemble a seamless integration of things. However, from a technical point of view, the availability and access to this data remains a challenge and are subject to actual technical implementation. This matter is expanded further in Section 6.3. Although the availability of data within paradigms such as Industry 4.0 and Digital Twins is crucial to users, several constraints hinder its usability in a shared linked data environment. These constraints can range from data ownership (Who owns which part of the linked model?), data sharing/trust (Are users comfortable sharing all parts of their data models?), and personal data gathering (Are users comfortable of a system monitoring their collaboration actions and decisions real-time?) to data security. Future research steps need to be taken to develop efficient ways on making such data available, connected, and accessible on demand.
6.2 Data modeling perspective
Integrated model data that can be used to filter model objects according to user needs were introduced, as shown in the examples in Section 5.5. The abstract representation of a complex socio–technical system can bring numerous benefits in terms of interoperability, knowledge storage and management. Additionally, the integration of data from heterogeneous sources (e.g., tasks, costs, resource availability or design objectives) can be suitable for capturing complex project management problems and their eventual connection to simulation and optimization algorithms.
Technical limitations regarding the version of imported IFC ontologies were outlined in Sections 4 and 5.2. The current focus is set on reusing IfcOwl concepts because of the scale and the interoperability that the IFC schema provides. However, the size and high expressivity of semantics can hinder efficient querying. Thus, several short descriptions of 4D modeling concepts have been proposed for the current context. A similar process can be adopted in other relevant domains (Section 4) or any sources of information on the web to enrich semantics and context that can be used to add value to the overall user experience.
6.3 Implementation perspective
From an implementation perspective, Sections 5.4 and 5.5 outlined a simplified way to populate and test the 4DCollab ontology. The testing addressed a few simple examples of querying a knowledge base. The construction of queries is subject to development and actual developer knowledge of the ontologies used. However, in the context of real-life day-to-day usage, validating a system that runs on linked data using ontology models depends on several factors:
• Data capture: Building model data are captured via the connection to IfcOwl, but capturing social context information remains a challenge. For example, the capture of user interactions on the model depends on the front-end system used to record each action, whereas other sources of human collaboration (i.e., verbal communication, decision formalization, etc.) remain a subject of future research;
• Data access: In principle, the linking of schema level models guarantees a level of interoperability, but does not guarantee data access or availability. Ontologies are governed by Open World Assumptions, meaning that missing model data can be assumed as “true”, “false” and “unknown”;
• Data validation: The data are not always valid or correct even though data about the model and the real-world interactions have been captured and are accessible across collaborative devices. Measures have to be taken to ensure that each “Session” has access to the latest correct data about the construction planning and documentation.
7 Conclusions and future work
A novel way of representing the semantics around SCSs within the context of BIM-supported project planning was outlined by introducing the 4DCollab ontology under development. An ontology engineering methodology was used by which nearby ontological fields were identified and discussed. The main concepts and overall syntax of the ontology were presented using the initially posed competency questions along with reused IFC schema classes. Several concepts and their interactions were discussed theoretically and technically. Subsequently, the represented model was tested by implementing a graph database on a system under development. Several queries were tested, showing their potential in providing SCS with relevant data and answers. The ontological model structure is expected to change and evolve after further testing in different case studies and scenarios. This process is conventional for models under development. That is, these processes are adapted in terms of concept connections (edges between graph nodes) and by adding/removing data properties for certain concepts. Additionally, the efficiency of traversing the graph model plays an important role in defining its structure, as discussed in Section 6.2.
Future work will focus on addressing the specified technical and implementation limitations by developing a system prototype architecture that can use the described ontology models for data access, processing and reasoning capabilities.
PDF
(1806KB)
