Ifd:Second LexiCon-BARBi Unification workshop

From dev.ifd-library.org

Bergen, 2006-02-06/10 Håvard Bell, Lars Bjørkhaug, Kees Woestenenk

Contents 1 Semantical issues 1.1 Naming of Relationships 1.2 Value assignments 1.3 Geometry 1.4 Illustrations 1.5 Language code 1.6 Shape 1.7 Full Names, Short Names and Plurals 1.8 Unit naming 1.9 Formulae 1.10 Complex property 1.11 Property heading 1.12 Contracts, legal issues 1.13 Events 1.14 Function, role 1.15 GUID format 1.16 Preferred Name and Preferred Description 1.17 Description constraint 1.18 Owner 1.19 History 1.20 Status 1.21 Comments 1.22 Users 1.23 Responsible organization 1.24 Support for Users (Helpdesk)? 2 API

Semantical issues

Naming of Relationships

It is agreed that Relationships may have assigned Names, whenever these are Names of a role of the Assigned Object in that Relationship. A Relationship name should be used when there is a need to further distinguish the role of the Assigned Object in a Relationship. When a Relationship does express a role that is already sufficiently implied in the Name of the Assigned Object(s), the Relationship will remain unnamed. Generally a Role name is needed if the cardinality of the Assignment of the same Object is greater than 1.

Examples The Relationship expressing that a Wall frame is has a number of Studs assigns each Stud to the Wall in a distinct Part-of Relationship, identifying each Stud as a Role name, such as “Stud nr 1”.

We all agree that the stud numbering was a very bad example of the use of naming of relationships. Naming of relationships is very useful for naming of properties that are dependent on their assignment to the subject. Like "frame width" that in reality is a "size" that in the assignment to a frame becomes a conceptual property.

The Relationship expressing that a Table top is a part of a Table does not need an additional Role name, since this Part-of Relationship is clear in itself. The Relationship expressing that Hydrogen oxide has two atoms of Hydrogen and one atom of Oxygen, is resolved by two Assignments of the Property “Count”, where one Relationship has the Role name “Number of Hydrogen atoms”, and the other “Number of Oxygen atoms”.

Modelling consequences: Since xtdRelationship is derived from xtdRoot, the current model requires a Relationship to have a Set[1-?] of Names and an optional Set[1:?] of Descriptions. Allowing Relationships without a Name requires the the Set[1:?] of Names to be optional or to be modified in Set[0:?]. Another possibility is to use default Names that are the Names of the Related Objects, as is current practice in the LexiCon.

Agreed solution Both LexiCon and BARBi will create context dependent properties by instantiation of xtdProperty rather than by use of naming of relationships. The latter is a powerful and useful solution but may be hard to communicate to the users. It would also imply changes to the model in regards of how values are assigned to properties.

A consequence of the agreed solution is that we will not name relationships in the IFD library. We are therefore breaking the rule of [1:?] on the Name attribute according to the standard. The current rolenames as used in LexiCon will be converted into subtypes of the related concept.

Value assignments

Values might be assigned as Generic Values, which apply to all assignments of the Measures they are assigned to. Values might also be limited to be valid only in a particular case when a Property is assigned to another Object. The way this is solved currently in the LexiCon differs from the way it is modelled in ISO 12006-3; it is expected however that the mechanism provided by ISO 12006-3 is able to provide this required functionality. In the model of ISO 12006-3, xtdRelAssignsPropertyWithValues is similar to xtdRelAssignsProperties, but has in addition a connection to xtdValues for a List of assigned Values applicable for this Relationship.

Examples A Measure might have a list of Colours (Red, Green, Blue, …), but when assigned to an Object only one Colour is valid in that assignment. A Value that contains a Size is only valid in a particular assignment, such as the Width of an Object.

Discussion: In LexiCon a “Frame shape” is described as a Subject composed of four other Subjects: a “Head”, a “Left jamb”, a “Right jamb” and a “Sill”. All these components have Properties “Height”, “Depth”, “Width”, “Rotation”, “Translation”, describing their geometry. As a separate entity the Head has a Depth with the Value “1.0”, but as a component of the Frame shape this Value is “0.1”. Using xtdRelAssignsPropertyWithValues there is a RelatingObject (“Head”), a Related Property (“Depth”) and a List[1:?] of RelatedValues. This Relationship does not clarify which Value (“1.0” and “0.1”) is valid in the case of the single Subject and in the case of its role as a Component.

In LexiCon this is resolved by assigning a Value to a Relationship (e.g xtdRelComposes): the Value “1.0” is assigned to Depth of Head as aninde ipendent Subject (using xtdRelAssignsPropertyWithValues), and the Value “0.1” is assigned to Depth of Head as a Component of Frame shape (using xtdRelAssignsPropertyWithValues with xtdRelComposes instead of xtdObject as RelatingObject).

Agreed solution Following the resolution from "Naming of Relationships" there is no longer a need to change anything regarding assignments of values. The relationship "xtdRelAssignsPropertyWithValues" can be used for this purpose.

Geometry

It is required that parametric 3D geometrical information can be stored in the Library, using the ISO 12006-3 structure. It is also required that this information can be exchanged using IFC. In addition, this information should be fit to produce VRML files. It has to be investigated whether Open GL, as currently used by the LexiCon, is the appropriate format.

There is a new initiaitve, called U3D with more information at Intels website, that is supposed to do exactly what we want. We should further investigate this. The latest draft as of 2006.04.26 can be found here: http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-363.pdf

Illustrations

It is required that the library can store images, video and audio, and provides methods to show these. The storage of these data should be internal, avoiding storage in referenced separate files. The schema of ISO 12006-3 should be extended to support this.

Modelling consequences: xtdRoot might have an additional optional attribute “Illustrations S[1:?]” with a new type “xtdIllustration” of type BLOB (if such a type exists in EXPRESS)

Resolution: A new entity xtdIllustration is added to the model. The new entity is not a subtype of anything in the existing model. The entity has an attribute "illustrates S[1:?] that points to the concepts being illustrated. There are two additional attributes; "MimeType" and "Illustration". The illustation is the binary object being the illustration itself, while the MimeType tells you the file format of the illustration.

We will use standard MIME types to describe the media. (http://www.iana.org/assignments/media-types/).

Language code

The model of ISO 12006-3 will be extended with a new attribute LanguageCode of xtdLanguage, to identify a language by a code based on ISO 639 and ISO 3166 (http://en.wikipedia.org/wiki/List_of_ISO_639_codes), consisting of a three character code of the language (lower case) and a three character code for the country (upper case) (http://en.wikipedia.org/wiki/ISO_3166-1_alpha-3) connected with a hyphen, so British English would be coded as “eng-GBR”, US English as “eng-USA” and Norwegian bokmål as “nob-NOR”. This allows searches for English terms independently from the country. It is agreed that the Unified Library will contain the complete list of ISO 639 – ISO 3166, and in addition the artificial languages as mentioned elsewhere (Open GL, MathML, etc.).

To look up a language code for a particular country go to: http://www.ethnologue.com/show_country.asp?name=GB Get the two letter country code here: http://en.wikipedia.org/wiki/ISO_3166-1_alpha-2

Modelling consequences: Language codes may be implemented as an Enumerated list that can be attributed to xtdLanguage (optional, additional attribute?).

Resolution: A new xtdLanguage instance will be created for every new combination of country and language. The LanguageCode attribute will store the "countrycode-languagecode" combination. E.g "eng-GBR" exactly in this form. LanguageNameInSelf will be the name of the language in the language itself and LanguageNameInEnglish will be the language name in international English with a capital letter in the start of each word. E.g "Norwegian Bokmål"

Shape

The SHAPE type currently used by LexiCon to identify Shapes in Open GL will be replaced by Subjects with a Name in Open GL language, which language will be added to provide access to Open GL types. Modelling consequences: None, if Shapes are implemented as xtdSubject with a type Name in the appropriate “geometrical language”, identified by one of the language codes in the Enumerated list of languages.

Full Names, Short Names and Plurals

xtdName will be subtyped into Full Name, Short Name and optional Plural. Possibly “Lexemes” can be used to resolve different forms of a term.

Resolution Two new entities xtdShortName and xtdLexime are added to the model as subtypes of xtdName. Short name will hold short names or abbreviations like "mm" for millimetre. A lexeme is an abstract unit of morphological analysis in linguistics, that roughly corresponds to a set of words that are different forms of "the same word". For example, English run, runs, ran and running are forms of the same lexeme. A related concept is the lemma (or citation form), which is a particular form of a lexeme that is chosen by convention to represent a canonical form of a lexeme. Lemmas are used in dictionaries as the headwords, and other forms of a lexeme are often listed later in the entry if they are unusual in some way.” (http://en.wikipedia.org/wiki/Lexemes).

Unit naming

Short Names of Units will use the writing style currently used in the LexiCon (example: reciprocal second per steradian square metre is written “1/(s.sr.m2)”). In addition a language Latex will be added to allow representation in a mathematical language.

Discussion: Latex is a format for typesetting, which needs a interpreting engine to transform to a representation in png, or html. It doesn’t seem appropriate to treat Latex as a separate language, because the language for the content is still needed. A better way would be to adopt Latex as the format for text in the library and have an interpreting engine built-in in the Web Service software. Maybe MathMl could be used as an alternative to Latex. Since MathMl is a W3C product it might be preferable.

Resolution We will use MathMl as a markup language for mathematic formulas and units. MathML will be treated as a separate language. The API will always return the MathML regardless of which language has been selected.

Formulae

Use a specialized language (e.g. MathML or tools like Mathematica and Maple) for writing formulae, used for example to add semantics to Units, or to use with Properties and (geometrical) dependencies between parts.

Discussion: Latex can also be used for writing formulae. What is needed in addition is a way to store semantics of formulae in the library, which would especially be necessary for dependencies between values of Properties. Example: if the height of a Frame is changed, then the length of the jambs should change accordingly. This requires methods for writing and interpreting statements like: “Jamb.Length = Frame.Height minus (Head.Width plus Sill.Width)”.

Modelling consequences: The statement above should be used as the Value of the Length Property of the Jamb, when it is a Component of Frame. This Value could be stored as Text, but then the semantics are lost. If xtdText is modified as suggested above then this kind of semantics can probably be stored. Consequences for IFC: As far as I know, IFC doesn’t support parametrics, nor this kind of dependencies. On the other hand, CAD applications might provide algorithms how to solve this. Any solution should then be discussed with IAI.

Resolution As for units we will use MathMl as a markup language for mathematic formulas and units. MathML will be treated as a separate language. The API will always return the MathML regardless of which language has been selected.

The problem of dependencies between properties is not yet resolved. We will have to look further into this issue.

Complex property

It is agreed that Complex Properties for grouping of interdependent Properties, as currently used in LexiCon, are supported. Example: a Cartesian coordinate is a grouping of an X-coordinate, a Y-coordinate and a Z-coordinate.

Modelling consequences: None. xtdRelAssignsProperties the Relating Object of type xtdObject might be of type xtdProperty. More specific is to derive a new type xtdRelCompoundProperty where the Relating type is a Property, with an additional rule that the Relating Property cannot have MeasureWithUnit or Values assigned to it.

Resolved The following rule applies: A complex property cannot have a measure. The properties it consists of will carry their own measures. Complex properties are made up using xtdRelComposes.

Property heading

It is agreed that optional Property headings for informal grouping of Properties under a heading, as currently used in BARBi, are supported. Modelling consequences: None. xtdCollection can be used for this.

Contracts, legal issues

It is agreed to have information related to contracts, clauses, regulations, certificates, etc. as subtypes of xtdSubject. Similar issues, like Streams and Software will be treated the same way.

Discussion: A Contract can be understood as a set of Clauses, so when Contract and Clause are both of type xtdSubject, Clauses can be part of a Contract through xtdRelComposes. A Clause as a type of xtdSubject is a bit problematic, however. Normally a Clause in the real world consists of an amount of text. In the case of standard Clauses (which are the ones to be stored in the library), Clauses might have parameters to be filled with project dependent content, such as the name of one of the contract partners, or a date, or an amount of money, etc. So, maybe it is better to treat a Clause as a Property with a Text Value, where the text can be formatted with parametric values (like “printf” in the C/ C++ language). In this case another Value type of Parametric text is needed in the model.

Resolution Two alternatives are possible. One using C/C++/PHP etc. format like: sprintf("%04d-%02d-%02d", $year, $month, $day); The other using self defined xml format. We will prefer the XML format using the following tags:

<formattedphrase>
 <phrase>
  <text>Please fill inn the date</text>
  <variable id="date"> </variable>
  <text>and the time</text>
  <variable id="time"> </variable>
  <text>. Thank you.</text>  
 </phrase>
 <values>
  <guid ref="date">odoofod-sdfgsdfg</guid>
  <guid ref="time">dfsdg-sdfgsdfg</guid>
 </values>
</formattedphrase>

Events

It is agreed that Events are treated as subtypes of xtdActivity. Impact, Load It is agreed that Impact, Load, etc. are treated as subtypes of xtdActivity.

Function, role

It is agreed that a Function will be treated as a subtype of xtdProperty, with a Measure that has a class Unit, and a list of named functions, that allows for multiple selection.

Modelling consequences: Units of type “class” can be implemented in the current model. The model doesn’t provide enumerated lists as value types. It is possible to have a list of Text values, and have that interpreted as an enumeration, but this cannot be recognized as such. In addition, it is not possible to add a description to an enumerated Value. This could be solved by adding an Enumeration Value type, consisting of a language dependent Text attribute, an optional language dependent Description attribute and an optional Reference attribute.

Resolution ValueDomain L[1:?] will exclusively be used for enumerations. For any other assignment of values to measures we will use the xtdRelAssignsValues relationship.

GUID format

The Unified Library will use GUIDs which are 22-character compressed GUIDs, using the base 64 compression algorithm defined in the IFC 2x2 Final for the type IfcGloballyUniqueId with “0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz_$” as the base characters.

Modelling consequences: The description of xtdGlobalUniqueID has to be adjusted.

Resolution The standard allows for use of compressed GUIDs. We will use the 22 character string as described above. We will propose to further restrict the GUID format in the ISO 12006-3 standard.

Preferred Name and Preferred Description

A model extending the model of ISO 12006-3 will contain a relation that selects Preferred Names and Preferred Descriptions assigned to an Object, in combination with an “owner” that owns this preference. For one Object only one Preferred Name or Description may exist for a certain language.

Modelling consequences: Replace the direct Name and Description attributes by a relation assigning a Name or a Description to xtdRoot, with additional attributes Preferred (Boolean or Logical) and Owner.

Solution Two new entitities xtdRelPreferred and xtdOrganisation are added to the model. xtdRelPreferred points to a concept (xtdRoot), its preferred names and descriptions (xtdLanguageRepresentation) and to the organisation (xtdOrganisation) setting the preference.

Description constraint

One Description can only be assigned to a single Object. Modelling consequences: Add a rule for the Description attribute of xtdRoot.

Resoultion A new where rule will be added to the modified EXPRESS schema.

Owner

A model extending the model of ISO 12006-3 will contain an entity Owner with attributes “Name” and optional “URL”.

Solution Three new attributes Maintains S[1:?], Name and URL are added to xtdOrganisation. Maintains points to the concepts of interest for that particular organisation.

History

Things that at least should be kept for xtdRoot derived types: - Creator, Editor (user, date).

Status

The status is only required for xtdObject and xtdExternalDocument derived types. The following status levels are distinguished:

• DRAFT
• CHECKED
• APPROVED
• INVALID
• TRANSFERRED

Promotion mechanism A promotion mechanism is needed, as well as handling requests for Objects with status INVALIDATED. For this, GUID relationships have to be maintained for Objects being transferred and for duplicate Objects.

Discussion: The name “Quality class” is somewhat misleading. A better name might be “Status”. An additional status might be “TRANSFERRED” in which case the target GUID should be stored. This means that for this target GUID an optional attribute has to be added that will be empty as long as the entity has not been transferred.

Resolution A new attribute "Status" is added to xtdObject and xtdExternalDocument. The statuses are stored in an enumeration (xtdStatusEnumeration). When a status for a concept is "TRANSFERRED" the VersionId will carry the GUID of the concept replacing the transferred concept. Transferred is synonym to merging concepts.

Comments

Comments can be made for xtdObject and xtdRelationship and xtdCollection derived types. Stored with a Comment are the author and the date. At start, Comments will be stored as a flat list per discussed item. Discussion: It would be useful to extent Descriptions also with an author or reference.

Users

• Roles based access: privileges of the user are restricted by the role the user belongs to. Suggested roles: super-user, editor, commentor, reader.

Roles can be dependent of fees. a User can belong to more than one Role

• Context: the user can customize the system to his preference.
• Rating system for Users (like Wikipedia)?

Responsible organization

Who owns the library, who can be addressed?

Support for Users (Helpdesk)?

API

The API provides the interface between applications and the Unified Library. The API is a provided as a Web service, as well as a DLL (or similar) for off-line use of the Library.

• The specification for the API can be found here: Ifd:IFD_API

“According to the W3C a Web service is a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface that is described in a machine-processable format such as WSDL. Other systems interact with the Web service in a manner prescribed by its interface using messages, which may be enclosed in a SOAP envelope, or follow a REST approach. These messages are typically conveyed using HTTP, and normally comprise XML in conjunction with other Web-related standards. Software applications written in various programming languages and running on various platforms can use web services to exchange data over computer networks like the Internet in a manner similar to inter-process communication on a single computer. This interoperability (for example, between Java and Python, or Microsoft Windows and Linux applications) is due to the use of open standards. OASIS and the W3C are the primary committees responsible for the architecture and standardization of web services. To improve interoperability between web service implementations, the WS-I organization has been developing a series of profiles to further define the standards involved.” (http://en.wikipedia.org/wiki/Web_service).

For off-line use of the API an update-mechanism has to be provided for downloading the latest version of the Library. Off-line use will be limited to reading only.

The API will be based on the model of ISO 12006-3 and the extensions as formulated before. The API should as much as possible formalize the operations as implemented currently in BARBi and LexiCon. Although the current GUIs of BARBi and LexiCon should be able to function with the API without modification, certain modifications of the GUIs will be unavoidable.

Return to the LexiCon - BARBi unification page