Ifd:First LexiCon-BARBi Unification workshop

From dev.ifd-library.org

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

This is the original document from the first workshop with comments from 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 Quality class 1.21 Propmotion mechanism 1.22 Comments 1.23 Users 1.24 Responsible organization 1.25 Support for Users (Helpdesk)? 1.26 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”. 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.

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 an 
independent 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).
Conclusion: the model has to be modified or extended for this kind of assignment.

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.

Modelling consequences:?

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)

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, 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?).

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.

Discussion:
“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.” (Wikipedia).
A possibility is to identify xtdName as the lemna, allowing a set of other forms of the term to be attatched.
Modelling consequences:
Change the attribute Name into Lemna and add an optional attribute Lexeme S[1:?] for different forms.

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.

Modelling consequences: Modify xtdText to accept Latex or MathMl.

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.

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.

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.

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.

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.

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.

Description constraint

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

Owner

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

History

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

Quality class

The quality class is only required for xtdObject derived types. The following quality levels are distinguished:

• DRAFT
• CHECKED
• APPROVED
• INVALID

Propmotion 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.

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.

“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