Semantic Concepts

Kees Woestenenk, 2012-04-04

Semantic Concepts provides access to the buildingSMART Data Dictionary (bSDD), also known as IFD LIBRARY for buildingSMART (IFD). It also provides access to the Semantic Concepts Library (SC), which is a more strictly structured subset of IFD.

The main part of Semantic Concepts is the BROWSER where you can search for Concepts and look at the description and definition of each Concept contained in either bsDD or SC. Currently you are on the INFO pages, where you can find background information about the Dictionary/Library. A bit of history is given under the ABOUT tab. There is room for DISCUSSION and of course there is the possibility for CONTACT. Below you will find the background information with on the left panel links to more specific subjects. The information is organized in levels of detail, where appropriate you will find links to dig deeper.

The buildingSMART Data Dictionary (bSDD | IFD)

The buildingSMART Data Dictionary is based on the ISO Standard ISO 12006-3 (2007): "Building construction — Organization of information about construction works — Part 3: Framework for object-oriented information". The acronym IFD stems from this standard and stands for International Framework for Data dictionaries; the name IFD LIBRARY for buildingSMART (IFD) has later been changed to buildingSMART Data Dictionary (bSDD) when it was adoptded by the buildingSMART organization. ISO 12006-3 describes a formal structure that allows information to be stored in a computer interpretable manner. There is a discussion whether to call the content based on that strcuture a Library, Dictionary or Vocabulary, and also names like Taxonomy and Ontology are used.

The subtitle of ISO 12006-3 mentions Object Orientation, a paradigm quite common nowadays in Information Technology. The basic idea of this paradigm is that the world of information is grouped into Objects, cells of information with a rather strict boundary, with their own behavior and with data stored as attributes. In bSDD the Objects are Concepts, which means Types, Classes, Categories or Families of Objects. Concepts are abstractions of real-world Things, such as Bricks, Activities, such as Brick laying, Characteristics, such as Length. ISO 12006-3 calls a Thing xtdObject and distinguishes the following range of subtypes: xtdSubject, xtdActivity, xtdProperty, xtdMeasureWithUnit, xtdUnit, xtdValue, xtdActor. For relationships between Concepts there are additional main classes: xtdCollection and xtdRelationship, and for references to external information there is the class xtdExternalDocument. Common for all concepts is that they have Names (xtdName) and Descriptions (xrdDescription), both of these are language dependent. Concepts may have many Names in diferent languages, which are regarded as synonyms when associated with a Concept. Finally, each Concept has a unique identifier (xtdGloblaUniqueIdentifier) and some administrative attributes. For a complete overview of the structure described in ISO 12006-3, modelled in UML, see the xtdClassDiagram.

bSDD uses a simplified model derived from ISO 12006-3. This model is described in the documentation of the WSDL (Webservice Definition Language) interface to IFD: IFD API. See also the IfdClassDiagram, modeled in UML. One difference is that there is one main class IfdConcept with subclasses IfdMeasure, IfdValue and IfdConceptInRelationship, and separate classes for IfdContext, IfdOrganization and IfdUser. The subtypes of xtdObject (xtdSubject, xtdActivity, xtdProperty, xtdMeasureWithUnit, xtdUnit, xtdValue, xtdActor) are now of type IfdConcept, distinguished by an Enumeration. The class xtdExternalDocument is regarded an IfdConcept with Enumeration DOCUMENT.

bSDD has no additional rules for its content, apart from the requirement that content must conform to the structure described in API. As described in IFD in a Nutshell, bSDD can contain many types of structures, but does not impose a particular one.

The Semantic Concepts Library (SC)

The Semantic Concepts Library originates from the STABU LexiCon, developed within the STABU Foundation. A first draft of that model was presented in An Information Framework for the Construction Industry (Kees Woestenenk, STABU 1997). The STABU LexiCon has contributed to the realization of ISO 12006-3 and is further developed in parallel. The UML Class Diagram of the current version is presented as IFD-NL Class Diagram. As a distinction to other diagrams the names of the entities are proceeded with the characters "lx". For a more informal overview of the structure see the tab SC BASIC STRUCTURE.

SC maintains its own database, the content, however, is being uploaded to bSDD. Using the BROWSER you can choose wether to browse IFD, using the WSDL interface, or to browse the SC database. When browsing IFD you will find all contained Concepts, including SC concepts, in SC you will retrieve SC concepts only. Depending on the synchronization rate, temporary differences between SC and IFD may occur.

As mentioned above, SC is a subset of bSDD, but its content is more strictly organized. A set of rules has been developed and is still developed further.

SC uses a Specialization hierarchy, which makes it a Taxonomy, but instead of a single hierarchical structure, as is usual for a Taxonomy, it uses Multiple Inheritance, meaning that a Concept can be derived from more than one supertype. In IFD Specialization is a possibility, but not enforced, some IFD Concepts are not placed in such a hierarchy, for SC Specialization is an essential part. Specialization means that Concepts on the higher level are more abstract than Concepts on lower levels; on the lowest level Concepts can be almost as concrete as a single Object. Specialization also means that derived Concepts as subtypes have a similar, but more extensive definition as their supertypes. One way is Specialization is replacing a Concept that is used in the Definition by one of that Concept's subtypes, or by adding another Concept to the Definition. This way new subtypes can easily be created if the current Concept is not specific enough. The most abstract Concept (the root or top of all hierarchies) is the Concept Concept. The first level of Specialization below Concept contains the Concepts Semantic concept, Semantic characteristic and Semantic collection. A Semantic concept is the supertype of all Things and Activities, corresponding with xtdSubject and xtdActivity in ISO 12006-3. Semantic characteristic bundles Property (corresponding with xtdProperty), Measure (xtdMeasureWithUnit) and Unit (xtdUnit). A Property is a Concept used to hold information about Semantic concepts, with Measures and Units to make Properties measurable. Values contain the actual data; in SC Values are not treated as distinct Concepts, but just as placeholders. For example, the Property Length can be measured with a Length measure that uses m as a Unit, and that has a Value of 72. A Semantic collection is a set of Concepts with an identity. One of the subtypes is Thematic collection, with Concepts like Fire resistance, Durability, etc.

As in IFD, a Concept may have multiple Names and Descriptions, a Global Unique Identifier provided by IFD, its own SC identifier and some administrative data. For each Concept associations with External documents can exist by means of References (xtdRelDocuments). Because IFD treats Documents as Concepts there is a difficulty in storing SC References in IFD, an issue that has yet to be resolved.

Each Concept also has a Definition, consisting of Defining concepts, and grouped into the categories Interaction (corresponding with the xtdRelActsUpon Relationship), Components (xtdRelComposes), Properties (xtdRelAssignsProperties), Measures (xtdRelAssignsMeasures) and Units (xtdRelAssignsUnits). Measures are only associated with Properties, Units only with Measures; the other types can be used defining Semantic concepts and Semantic collections.

Interactions define the behavior, involvement or function of a Concept. For example, An Accommodation (the Concept being defined) has the function Accommodating, where the Concept Accommodating has its own Definition as an Activity.

Components are typical parts of a Concept. In the example of Accommodation, the typical parts are Bottom, Side boundary, Upper boundary and Air. Each of these Components is a Concept in its own right with again its own Definition.

Properties are typical Properties for a Concept. In the example of Accommodation, a typical property is Space temperature, again a Concept with its own Definition.

In SC a Concept of type Semantic concept is regarded through its whole lifetime, from cradle to grave. Hence, a Component of Masonry work (which is seen as a Result) is Brick laying. This Defintion allows Masonry work to be instantiated for different life stages, such as a ready result or as to be when the work has not yet be done.

The use of Concepts in Interaction and Composition relationships creates a complex Semantic network that, once in place, can be very helpful to find interdependicies in projects.

Currently, many Concepts in SC are not completely (or sometimes not at all) defined as described here, so there is still a lot of work to be done. For a proper Definition specialists are needed; once a proper Definition is in place, this Definition should provide the necessary bakground information for Objects in projects that are derived from them.

The BROWSER shows all information of a Concept that is selected as decribed above. In addition it shows where the Concept is situated in the Specialization hierarchy, by listing its Supertypes and Subtypes, and it shows, under the heading Usage, which other Concepts use the Concept in their Definitions. Clicking on a Concept that is either part of the Definition, or a supertype or subtype, or is listed under Usage, will open a new window with the Definition of that Concept.

XML and Webservice

Definitions of Concepts can be viewed in an XML structure by clicking the XML button on the BROWSER page.

A List of Concepts and definitions of Concepts can be obtained through a simple webservice. The webservice provides 2 messages: getConcept and searchConcepts.

getConcept must be called with a string parameter containing the ID. The definiton returned by the webservice only shows the parts of the Concept that are relevant for he definition:

  • the administrative data of a Concept
  • the descriptions
  • a list of interactions as references to the interacting Concepts
  • a list of components as references to the composing Concepts
  • a list of properties of Concepts that are of type ACTIVITY or SUBJECT, and associated lists of propertymeasures and conceptvalues
  • a list of measures of Concepts of type PROPERTY
  • a list of units of Concepts of type MEASURE.

searchConcepts must be called with a search string, similar to the search string as used in the browser. A list of concepts is returned, each concept containg its ID, the Title in English and the Title in Dutch.

The URL of the WSDL file of the webservice is: