Second plenary meeting of the CEN econstruction workshop . We try to bash together standards (well, five documents we say we agree on) for "electronic construction". At the moment we're gathering information from existing standards and projects. First some links to the relevant documents:
CEN needs to have no restriction regarding copyright. If you bring something in they need to be able to publish it. The other way round you may run into problems if you publish something that's almost equal to a CEN document.
I raised the problem of publishing xml formats or something similar in CEN documents. You have to publish that format for free on the internet without having to pay a fee to CEN for just looking at it. According to CEN the CWAs are available for free on the internet.
They distributed the actual legal documents regarding this problem. The copyright remains with the original author, but CEN needs the right to publish it. The only real restriction on you is that you cannot distribute it yourself as an alternative standard.
We got the confirmation that the CWAs (the documents we produce) will be available for free, as this workshop is funded by the eEurope EU activity which guarantees al material to be available for free.
XM7 is mentioned as being one of the most important initiatives at the moment. It integrates the ISO 12006-3 ("lexicon") with the IFC. If we interface with XM7 we get the IFC and the 12006-3 for free.
We'll invite comments on our documents from the ebxml project. We're not quite sure how much we have to relate to them at the moment. Ebxml is agreed to be important, but how large an overlap - if any - is there?
(Again: a CWA is a document produced by the workgroup, Cen Workshop Agreement).
First Michel Böhms gave a overview of the different CWAs. The first one aims to introduce all the terms. The second one goes a bit more in the ICT direction, telling what we are about to do. So CWA1 is "seeing" and CWA2 is about "doing". But we've done some projects and have experiences, so CWA3 intoduces the base components of the system that we think will be part of the eventual system. This will be quite a big document, so it's split into two, CWA3 and 4. So 1 and 2 are related and 3 and 4 are related.
To support our views we also need tools or pointers to tools. That's for CWA4 and 5 (which will be edited by CSTB: 4 by Celson, 5 by Remi).
I raised the point of confusing names. "Framework" sounds like "software framework" to me, while the document (CWA1) actually provides a generic industry overview instead of something ict-ish. Graham Storer suggested using descriptive sub-titles, which certainly solves the problem. In the end the discussion drifted to excecutive summaries, so I hope those subtitles make it it there...
Mostly roadcon sheets minus details plus some expanatory text, just as CWA2.
The first main dimension is the distinction on which level a project aims to influence the real world, the "impact level".
An important second dimension is the "innovation phase":
On every impact level (why - with what) you can look at things in the various innovation levels. Like on the ICT enabler level, what are the emarging trends and what is currently actually being used?
The CWA then uses this method to analyse a few trends and opportunities, looking for relevant directions.
The document in my opinion is a nice, short summary of the ROADCON project. The only lack is that it's not clear what you should do with the information in this CWA. It lacks a summary which tells me which information to take with me when reading the follow-up CWA2. The connection between CWA1 and 2 isn't clear enough. This will be fixed in the next version.
Nice comment: you can use CWA1 as a set of discussion-openers when talking with end-users instead of as a document that has to be actually read by those end-users. The from-emerging-to-used axis is a nice starting point for a discussion. What they are using now was a distant dream 10 years ago, which might make the end-user more perceptive to or appreciative of new technologies.
Especially nice: picture on page 14 {include it!}.
Michel believes that there should be an explicit distinction between definitions and specifications in the model somewhere. "Definition" means the definition of generic classes ("door", "foundation"). "Specification" means the (partly) filled-in definition ("this type of door has a height of 2 meters").
I agree with him that this distinction is probably necessary.
There was a lot of discussion on the resulting architecture slide (page 20) in CWA2. We decided to look at it a bit more and send suggestions to Michel. No generic discussion on the emaillist though (which I would have preferred actually).
CWA3 looked at existing metaschemas, looking what we can borrow/steal/reuse. And looking at what we want from a metaschema.
One thing that stands out is the distinction between a definition of a thing and a named instance of a certain thing (disctinction definition vs. specification from CWA2)).
Then the presentation continued with a distinction between a metaschema and an ontology. That pushed a few warning buttons with me. In my opinion a schema is almost the same as "dataformat". A meta-schema therefore is a dataformat for dataformats. XSD is the dataformat in which we expressed the bcxml vocabulary dataformat, so xsd would then be the meta-schema.
Now to the wrong buttons. According to CWA3, a meta-schema contains the more abstract objecs (generic chair definition for instance) and the ontology adds functions to those abstract objects... To me that knd of metaschema is just a more generic ontology. You describe the actual terminology used in the building industry, which comes close to the normal ontology-definition. A meta-schema in this case would be the OWL model, for instance.
If there is something meta-ish, the "normal' ontology layer would include doors and foundations and the meta-layer would include concepts like object, property and unit.
It turned out that everybody agreed upon this (some technicalities aside).
Jeffrey Wix advocated the use of value objects instead of raw values, to allow the changing of values for instance.
We had a small presentation about CWA4.
I liked the atmosphere at the meeting. We went through all three documents we wanted to address, so that was OK. The only thing is that we would have liked more people to show up in order to increase the number of comments.
My name is Reinout van Rees and I work a lot with Python (programming language) and Django (website framework). I live in The Netherlands and I'm happily married to Annie van Rees-Kooiman.
Most of my website content is in my weblog. You can keep up to date by subscribing to the automatic feeds (for instance with Google reader):
