OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

obix message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Interesting Conversation from the NBIMS world

Title: Re: Diagrams - data migration

Not that we are ready to interact yet, but somewhere past ICAL binding this comes into play




"There are a thousand hacking at the branches of evil to one who is striking at the root." -- David Thoreau

Toby Considine

Facilities Technology Office
University of North Carolina
Chapel Hill, NC


Email: Toby.Considine@ unc.edu
Phone: (919)962-9073




From: bounce-2021-435@lyris.nibs.org [mailto:bounce-2021-435@lyris.nibs.org] On Behalf Of Deborah MacPherson
Sent: Wednesday, August 15, 2007 1:53 PM
To: fic-bim
Subject: Re: Diagrams - data migration


The following information is forwarded to FIC-BIM from Matthew West Reference Data Architecture and Standards Manager at Shell International Petroleum Company Limited, via Deborah MacPherson WDG Architecture:

....talking about building requirements, we have a similar situation with requirements for process plants. We have noticed several layers:
 - Requirements specifications (what the customer wants)
 - standard parts - parts defined by a publicly available standard, and available competitively from multiple suppliers (e.g. nuts and bolts).
 - Manufacturers models - manufacturers specifications for their products.

Another piece of work I have done is ISO 18876 - Integration of industrial data for exchange, access and sharing (IIDEAS). This is an architectural level standard that shows what needs to be done to get different stuff to work together (at the data level) so in principle, it would show how the SemWeb stuff might be integrated with say a CORBA set up (if anyone still has that). But as I say, it sticks to what is necessary for data integration.


It seems to me that there are a couple of issues in what you are attempting that need to be addressed.
1. You are dealing with geography/maps at a number of levels:
 a) Identification by address.
 b) Identification by coordinates (in some - not one - known coordinate system)
 c) What is there (e.g. a building), and spatial representation of that by some local coordinate system.
How do you relate these to each other? How do you make this information accessible to different applications (suggests some standards, or smart ways of recognising the different forms of these).
2. What is the authoritative source for the information provided?
I think this is a much wider problem. One of the ways that we need to tame the web is to understand who is the authoritative source for different sorts of information. Ed Barkmeyer was talking yesterday about units of measure and scales, and who is really responsible for those, but you have them being provided here, there and everywhere without a link back to the authoritative sources.
I think a key role that public bodies can play is to establish and encourage authoritative sources, not least by recognising what information they are the authoritative sources for, staking a claim for that, and recognising and endorsing authoritative sources for other information they are not the source for.
Anyway, my two cents worth.


Matthew West
Reference Data Architecture and Standards Manager
Shell International Petroleum Company Limited
Registered in England and Wales
Registered number: 621148
Registered office: Shell Centre, London SE1 7NA, United Kingdom


On 8/14/07 8:30 AM, "Louis Hecht" <lhecht@opengeospatial.org> wrote:

Deborah - Jeff provided you with some excellent, but early and notional examples of how information models and ontologies might be utilized in AEC settings.

CEN, IAI and European Framework Programmes have certainly accomplished a good deal of ground by tackling XML encodings, organizing data exchanges, and exploring supply chain management. All of this previous work should be considered by the US BIM community and I believe NBIMS is the place to do that for the good of the greater community.

Alas, I know of no recent diagrams at a notional, informational, or systems level that connects the dots between building information, modeling and non-project-centric, life cycle overlaps and the layer cake diagram, W3 objectives, NBIMS scoping, independent BIM library building tasks, and Open Geospatial Consortium work. Hopefully, through the combined and coordinated work of BuildingSmart Alliance partners (both together and independently), continuing advancements of NBIMS and international work we can have that diagram available sooner rather than later.

Ontological capabilities remain rather immature at this time, and as you rightly point out a number of information, communications and technology community standards bodies like W3C and OASIS are hard at work in this area. OGC is also hard at work on making geospatial information more ontologically centric in tight coordination with W3C and OASIS and this includes a good deal of information of considerable value to the BIM community.

However, I would like to address your questions regarding XML.

XML is for marking up data -- But XML is not intended to be read primarily by humans and we should consider how such messages would appear to a machine, which doesn't have our level of knowledge and understanding.

XML does not provide semantics.  XML does not solve business problems.  XML Schemas do not provide semantics or solve business problems.  XML, by itself, does not solve interoperability problems, yet it is an important tool for doing so.

Your question points to the relationship between all the standards that make up the layer cake and the work so far accomplished by the AEC community which is principally many flavors of XML. These flavors of XML cannot easily talk to one another.  When a receiving system receives an XML message, it has to do something with it. It has to "parse" it and it has to "process it". It does the former using generic software that merely understands the structure and syntax.  It does the latter by applying what is often described as "business logic" or "business rules" to the XML message and the data items within it, so that the data can be validated, placed in appropriate locations for later processing, or shipped out to be displayed or edited by the user on his/her desktop via a user interface, etc.

This business logic has to process the data in the messages according to their meaning or semantics. This business logic must exist a priori - it must have been created from some information architecture model that describes the domain to which the message belongs. Currently that model is different for each vendor, and non-interoperability is the result, but this can be resolved with users and vendors working together in a neutral setting.

XML does not move nor become understandable without services, e.g, ftp or web services, and here again those services remain largely within each vendor's private domain.  Additional work needs to be done isolate the necessary functions of information systems that capture the advancements so far accomplished by the AEC community using a service environment that rests on standards based service interfaces. OGC is working to assist the AEC community on the service interface development and testing side of things... Developing open web services for building life cycle is needed and OGC's test bed procedures are the proven, efficient way to develop interoperable web services using the already developed flavors of AEC-related XMLs for the building life cycle.

It would be great if the community can demonstrate its collective resolve and the willingness to place resources behind the rhetoric and extend the XML flavors that are developed with standards based web services that are also within reach. A much fuller set of capabilities that approaches the NBIMS mission will result for the market. Ontologies and AEC standards-based semantic problem solving (also the province of standards bodies) will come more fluidly after consensus is reached on standards-based information service "architecture", and the diagrams you desire will be part of that fabric.

While not a diagram per se, I hope this explanation makes a positive contribution to yours and everyone's understanding.


Louis G. Hecht, Jr.
Open Geospatial Consortium, Inc.
Office: +1 301 365 5907
Cell:   +1 301 792 1365

At 11:47 AM -0400 7/31/07, Deborah MacPherson wrote:

Dear Dianne Davis,

Are the "DRAFT diagrams showing a change in information creation and BIM development" available?

Have you seen the recent w3 layer cake diagram http://www.w3.org/2007/03/layerCake.png? Ontolog and other forums are discussing, for example, positions of the proof and logic boxes here [Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/] under "Current Semantic Web Layer Cake".  

Where do you see realistic, non-project-centric, lifecycle overlaps between the layer cake diagram, W3 objectives, NBIMS scoping, independent BIM library building tasks, and open geospatial consortia? RDF and XML only?

Thank you,

Debbie MacPherson


Deborah MacPherson
Specifier CSI AIA
WDG Architecture PLLC
202 857 8300 x1184


Deborah MacPherson
Specifier CSI AIA
WDG Architecture PLLC
202 857 8300 x1184

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]