Identification of CBIM information objects

Guideline identification of CBIM information objects
Technical note

Inhoud

Introduction

CBIM objects are normally presented using their name and user ID attribute values. Although this identification method will be satisfactory for most users it is simply not reliable enough to count on. The unique identification of CBIM objects is a feature that usually is kept invisible to most users. Tools will suppress this bit of information because it is semantically irrelevant. Unique identification of information objects is a major concern for ICT applications to guarantee a reliable operation: they need to possess an attribute value they can count on to be different for each object instance always and everywhere.

Until recently the available COINS tools (COINS Navigator and API library) employed a simple method for assigning identification strings. For each model the object's local name was based on a serial number starting at 1 and incremented for each new object instance. In combination with the Uniform Resource Identifier (URI) of the model this produces a global unique identification following the format <model-uri>#<local-name> for example http://www.coinsweb.nl/pilots/strukton/carpark.owl#Function34. This strategy works fine when the object creation is centralized. However, CBIM objects will be created simultaneously at various locations in a, for the time being, semi-off-line way. This brought about the need for a globally unique naming convention which should be independent from the model URI although the designation of CBIM objects will still use the format <model-uri>#<local-name>. This policy offers the possibility to track CBIM objects over the Internet.

GUID's or UUID's

Creating globally unique identifications is a well described topic in the ICT literature. The term GUID usually refers to Microsoft's implementation of the Universally Unique Identifier (UUID) standard, however the term is common in applications not written by Microsoft, or for their operating systems. The GUID is a 16-byte (128-bit) number. GUID's are most commonly written in text as a sequence of hexadecimal digits such as: 3f2504e0-4f89-11d3-9a0c-0305e82c3301.

The guideline for the identification of CBIM information objects prescribes to exclusively use the string form of GUID's as the value for the local name attribute (rdf:ID) for all CBIM object classes. Because the syntax of a fragment identifier is defined as a NCName (XML "non-colonized" name) it should start with a letter or an underscore character. The guideline recommends the use of the underscore character.
For example: http://www.coinsweb.nl/pilots/strukton/carpark.owl#_3f2504e0-4f89-11d3-9a0c-0305e82c3301.

Object versions

In a COINS Building Information System information objects are never removed or modified. If the information content of a CBIM object need to be changed the original object instance will be marked expired while a new object instance will be created representing the new state of the original object (see also: http://www.coinsweb.nl/wiki/index.php/Version_management).

New object version after a modification.
New object version after a modification.

The new version of the object is primarily a clone of the original object, i.e. the local name attribute value (= the globally unique ID) will be copied, too. Yet, having two objects with identical ID's in the same name space cannot be allowed. For this reason the local name is extended with the version serial number separated by a dot character. By convention the initial version number (0) can be omitted.

This leads to the final form of a CBIM object identification (in BNF notation):

  • <CBIM-object-ID> ::= <model-ID> # <local-name>
  • <model-ID> ::= <model-name-space> / <model-file-name>
  • <local-name> ::= _<guid> | _<guid> . <version-number>
  • <version-number> ::= <integer>

For example: http://www.coinsweb.nl/pilots/strukton/carpark.owl#_3f2504e0-4f89-11d3-9a0c-0305e82c3301.2, which refers to an object version number 2.

Document references

CBIM objects can point to other CBIM objects using the guideline discussed above. Referring to information objects outside the CBIM name space is handled by objects of the CBIM Document class or descendant classes (e.g. Explicit 3D Representation and Visi Message). A document stored on a local file system can be addressed by its absolute file path. If the document is shipped in a COINS container the file path is re-routed to point to the doc folder of the container. Importing the container will result in unwrapping the document in the assigned local folder. A document need not to be physically transported if it can be reached over the Internet (this could be good practice for very large documents). The document is then addressed by its URI. Employing both the file path and URI address options could be handy to prevent downloading over and over again or to be able to operate off-line.

Usually the document will be addressed as a whole but sometimes the use of a fragment identifier could be convenient to link to a small portion in a large HTML document or to refer to a specific object in a shape representation model file. For example in an IFC model file the global ID attribute can be used to point to a specific object in the IFC file.

Afkomstig van CoinsWiki NL, de Vrije Encyclopedie. "http://www.coinsweb.nl/wiki/index.php/Identification_of_CBIM_information_objects"
Personal tools