bsp-forum
[Top] [All Lists]

[bsp-forum] Fwd: [Fwd: Permission to use image]

To: "Building Service Performance (BSP) Forum" <bsp-forum@xxxxxxxxxxxxxxxx>
From: "Deborah MacPherson" <debmacp@xxxxxxxxx>
Date: Sun, 30 Nov 2008 12:47:19 -0500
Message-id: <48f213f30811300947w2d880dev44e9bd31a8d9f299@xxxxxxxxxxxxxx>
Forwarded conversation
Subject: Permission to use image
------------------------

From: Deborah MacPherson <debmacp@xxxxxxxxx>
Date: Mon, Nov 24, 2008 at 11:12 AM
To: site-policy@xxxxxxxxxxxxxxxxxx, Deke Smith <dsmith@xxxxxxxx>


Dear OGC and buildingSMART alliance, 

This message is seeking permission to use the attached image from NBIMSv1 as part of a slideshow for a collaboration with the NIST National Institute of Standards and Technology, the Integrated Emergency Response Consortium, and collaborators from the Building Service Performance project at Ontolog.  An incomplete draft is here on Google Docs, the (work in progress) slideshow can be sent upon request or if you cannot access or open the link. 

Basically, the NBIMS hierarchy is used as a basis, or framework, for a series of emergency response communications based on a scenario developed by the NIST Building and Fire Research Lab. Working with the Integrated Emergency Response Consortium to link up these communication pathways and define the ideal requirements for exactly which information needs to issue from a BIM. 

There will be a demonstration in January, comments and participation are welcome. 

Please confirm either way. 

Sincerely, 

Deborah MacPherson

----------
From: Deke Smith <deke@xxxxxxxxx>

Deb,

Certainly you may use it.

Thank you.
Deke Smith

Mr. Dana K. "Deke" Smith, FAIA
Executive Director, building
SMART allianceTM
National Institute of Building Sciences
1090 Vermont Ave, NW, Suite 700 | Washington, DC 20005-4905
(202) 289-7800 x142  cell (703) 909-9670  direct (703) 481-9573
www.buildingsmartalliance.org

Please make plans today to attend the buildingSMART alliance National Conference:
Click here to find out more

 P Consider the environment. Please don't print this e-mail unless you really need to.

From: Deborah MacPherson [mailto:debmacp@xxxxxxxxx

thanks - wrapping up loose ends and wanted to be sure. 

----------
From: Louis Hecht, Jr. <lhecht@xxxxxxxxxxxxxxxxxx>


fyi...LGH

On Nov 25, 2008, at 12:18 PM, Sam A. Bacharach wrote:

Louis,
OGC is fine with it -- can you forward  to BsA?
Sam

-----Original Message-----
From: Greg Buehler [mailto:gbuehler@xxxxxxxxxxxxxxxxxx]

Louis, Sam,

FYI

I see no OGC content, so I would be inclined to say yes.

----------
From: Deborah MacPherson <debmacp@xxxxxxxxx>
Date: Tue, Nov 25, 2008 at 12:55 PM
To: "Louis Hecht, Jr." <lhecht@xxxxxxxxxxxxxxxxxx>


Thanks - I also sent to bSa and Deke said that was fine. 

FYI, those slides were based on these 2 paragraphs, just marked where to switch from slide 1 to 2 below but can provide. The scenario can be sent if anyone from OGC is interested is seeing how this shakes out. Ultimately will cross reference to response codes and EDXL framework which is generally being overseen by OASIS technical committees. 

Deborah
____________
 
"The scenario begins in a large commercial [1] building at 321 Prince Street [2], in a section of the third floor that is undergoing renovation. Contractors left out some vapor-producing chemicals that have ignited after-hours, producing a small explosion and starting a fire. The explosion disables the smoke alarm in the room, but this generates a trouble condition at the fire panel. The fire panel generates a Common Alerting Protocol (CAP) alert that is passed to the BISACS Base Server (BBS). The alert is then passed to the subscribing central station alarm (CSA) company that monitors the building. Upon receipt at the CSA, a representative attempts to contact the building personnel to verify the alert (smoke alarm trouble in room 310). While the CSA representative follows procedures to verify the alert, another alert arrives reporting a smoke alarm from the hallway outside 310. The CSA representative then immediately transmits these two alerts to 9-1-1 dispatch electronically, with both CAP alerts grouped together in a message.

The 9-1-1 dispatch center receives the CAP alerts with data fields from the message loaded into form fields in the Computer Aided Dispatch (CAD) software interface. At this point the dispatcher will see that there is a suspected fire in a commercial building at 321 Prince Street with smoke alarm trouble and alarm signals on the third floor. This likely indicates a working fire. The dispatcher will follow procedure to dispatch the jurisdiction's standard fire response to the building address. The CAD system will internally authorize each of these units to have access to building alerts and access to additional building incident data directly from the building BBS.  The CAD system will transmit the building alert data on to responding units who will have the alert data presented visually and/or audibly."

----------
From: Louis Hecht, Jr. <lhecht@xxxxxxxxxxxxxxxxxx>

Deborah - while we have no issue with you using the diagrams, there are significant issues that will need to be addressed to connect building information with EDXL. I presume you are aware of these issues, as most of them need to be addressed by a standards organization that possess a useful, credible and defendable approach. We are working to make NBIMS that kind of organization.

LGH

----------
From: Deborah MacPherson <debmacp@xxxxxxxxx>

Yes. Its a big problem. 

The team is comprised of Rex Brooks OASIS and Starbourne Communication Design, Michelle Raymond Honeywell Systems, Bob Smith former professor at CalState now with city of Huntington Beach and Toby Considine, OASIS OBiX technical chair - we are all in an early collaborative group  called Building Service Performance Project at Ontolog 

The scenario was started at NIST, led by David Holmberg, Alan Vihn and Jason Averill. A tremendous collaborator is David Coggeshell at MapLab. Plus participants from the Montgomery County MD fire department. Along with interest from Robert Anderson at Nemetchek and Kimon Onuma. Working towards a meeting in California on the 17th/18th to work out details and what can actually be done. 

It won't be easy but we aim to have a demonstration by January. 

Regards, 

Deborah
--

----------
From: Louis Hecht, Jr. <lhecht@xxxxxxxxxxxxxxxxxx>

Would suggest you include Carl Reed in the group...CTO of OGC and copied.

LGH

----------
From: Deborah MacPherson <debmacp@xxxxxxxxx>

Hi David H, Alan, Michelle, David C, Rex, Toby, Bob - 

Louis Hecht at OGC suggests Carl Reed CTO at OGC may be interested in the Building Emergency Response Scenario. For example, Louis Hecht stated ".....while we have no problem with you using the diagram, there are significant issues that will need to be addressed to connect building information with EDXL. I presume you are aware of these issues, as most of them need to be addressed by a standards organization that possess a useful, credible and defendable approach. We are working to make NBIMS that kind of organization."

I explained to the best of my limited knowledge the special expertise of the participants including OASIS TC, BSP, and everyone's sincere commitment to developing realistic, open standards. 

Perhaps we can discuss more on the conference call (time still TBD). 

Regards, 

Deborah

----------
From: Carl Reed <creed@xxxxxxxxxxxxxxxxxx>

Deborah
 
I would be happy to help where I can. As an FYI, I am involved in the following related activities:
 
1. Official liaison person from OGC staff to OASIS (as per our MoU with OASIS)
2. Participate on a regular basis in the Emergency Management TC
3. The liaison between the OGC and NENA and the NG 911 activity. I participate in two of the working groups for the NG 911 activity
4. Worked with the IETF GeoPriv, ECRIT, and SIP working groups for many years on location enabling a variety of internet standards that are of significant interest to the emergency response community.
5. Am an official document reviewer and participant of the ISO/JTC-1 SGSN activity. SGSN has to do with ubiquitous sensor systems, especially in-building systems. There are a number of EM use cases in their current draft document. This activity is also related to the u-City initiative in Korea. If you are interested in Building Emergency response, there is a wealth of info from these projects.
6. I am a participant in the W3C EM Ontology Incubator activity
7. Was on the NRC Committee on Planning for Catastrophe - Improving Geospatial Support for Disaster Management.
8. Also involved in a variety of OGC activities related to emergency response and risk mitigation.
 
The reason for providing this list is that I may be able to bring a multi-standards organization perspective to the work related to defining a Building Emergency Response Scenario.
 
Cheers

Carl

----------
From: Rex Brooks <rexb@xxxxxxxxxxxxxx>

Hi Deborah, Everyone,

Carl and I are both in the OASIS Emergency Management Technical Committee (EM TC). He chairs the GIS Subcommittee (EM GIS SC) and I co-chair the Messages and Notification Subcommittee (EM-Msg SC) and we have both worked on the EDXL Specifications. There are a several ways that a specification can be proposed for the EDXL family.

Where Building Emergency Response Information fits into EDXL is something that needs discussion, as does the best way to go about it. My initial thoughts are that Building Information Systems overlaps SensorML from OGC so I think that needs to be taken into consideration.

We just had a fairly long discussion about the place of sensor data in relation to the Common Alerting Protocol and the EDXL Distribution Element (EDXL-DE) in today's EM TC meeting with David Lamensdorf of the Emergency Interoperability Consortium (EIC) along with several folks from DHS Disaster Management.

Unfortunately, this area is not exactly simple. However, on the positive side, we are well along the way to being fairly certain that we have most of the people who need to be in the conversation involved.

Just as a for instance, Emergency Medical Information Systems is another area that doesn't fit well into a single discipline or Standards group, so I think there's a lot of preliminary discussion that needs to be done. Another existing standards initiative where, sensor data, gis data and building information data will almost certainly need to be included is the Situational Reporting specification that is currently being renewed under the DHS-EIC-OASIS Memorandum of Understand (or is it Memorandum of Agreement, I forget). Regardless, it is being taken up again in the Practitioner's Steering Group established under that memorandum and is hoped to be reported out as a candidate submission to the OASIS EM TC in Feb 09.

I'm open to a telecon.

Cheers,
Rex
--
Rex Brooks
President, CEO
Starbourne Communications Design
GeoAddress: 1361-A Addison
Berkeley, CA 94702
Tel: 510-898-0670

----------
From: Considine, Toby (Campus Services IT) <Toby.Considine@xxxxxxx>

I would like building sensors to be up to the level of SensorML. I would like building sensors to be up to the level of oBIX. Unfortunately, most building sensors are, at best, a disconnected tag with a number, floating in space....The problem is, how to query it in context...and to identify that context in a way that is useful to the emergency responder who may be worried about smoke and flames, or about bullets, or about anything other than interpreting Sensors as without context.

Today, we have hard coded building annunciators, often with idiot lights. These are protected because you must stand in front of them to access. If we are going to let a 911 operator connect to a building and access sensors, we need a more nuanced concept of security--and security can only come from context. We are stuck with the same problem.

If we imagine a world in which every building had a full three dimensional BIM in place, we could imagine the BIM providing the context, and the owner's security assertions about security being applied to the structures of the BIM. We can also imagine a very light-weight BIM able to be rendered on tiny devices. I like to imagine something between the BIM used in Sketch-Up and the context defined by GBXML (especially if AutoDesk follows through with its indicated intentions of moving this specification into an SDO). Perhaps a transform between those structures and TinySVG, with a new draft out next week, and already optimized for cell phones / PDAs would provide the context.

Alas, we are not in that world. I do notice that more than a few products have recently come to market able to read CAD drawings, particularly DWG, and one or multiple back end business databases, and generate interactive PDF's on the fly. These PDFs can be multi-page (multi-floor) and can contain links to back end detailed information. A scenario like that offers opportunities for both default implementation as well as business driven limitations to or explanations of revealed data.

Emergency Medical Information Systems is a good model to follow. In particular, as there is no cause to ever reveal personally identifiable information under HAVE, HAVE simply excludes any such data structure. Similar approaches applied to building information might make owners more willing to share the sort of data that emergency responders and 911 operators wish.

I have written more of my thoughts on this in the two articles below.

http://www.newdaedalus.com/articles/2008/11/21/the-sound-of-breaking-glass.html

http://www.newdaedalus.com/articles/2008/10/19/scada-security-building-systems-and-first-response.html

tc

"A man should never be ashamed to own that he has been in the wrong, which is but saying ... that he is wiser today than yesterday." -- Jonathan Swift

Toby Considine
Chair, OASIS oBIX TC
Facilities Technology Office
University of North Carolina
Chapel Hill, NC
  
Email: Toby.Considine@ unc.edu
Phone: (919)962-9073
http://www.oasis-open.org
blog: www.NewDaedalus.com

----------
From: Deborah MacPherson <debmacp@xxxxxxxxx>

Well this is very perfect. What an amazing group! Should we schedule a call for Friday afternoon perhaps via BSP so slides can be shared, call can be recorded and we can start this off with both feet planted firmly in the open world?

If Friday is too short notice for everyone (or for Peter Yim/CIM3) could be Monday or Tuesday next week? If so, I'll mark up where the slides should change and upload them to really start talking about the remainder of the scenario which is mapping the alerts to floorplans. 

Wow. 

Best Regards, 

Deborah
-- 
----------
From: Deborah MacPherson <debmacp@xxxxxxxxx>
Would you say a BIM providing the context is like IFC2x3 bindings? See the MVD group at NBIMS http://www.blis-project.org/IAI-MVD/? Looking forward to reading the links below. 

----------
From: Rex Brooks <rexb@xxxxxxxxxxxxxx>

Toby brings up a vital factor, or set of factors. First, I think we need to view most of these factors, from BIM to EDXL as essentially information and communication technology problems and less as electronics standards and equiment problems.

I think we can anticipate some incentives for both green and emergency retrofitting existing buildings, so that's where we can aim to have IT Sensor and EDXL standards written into those incentives. We also can expect to see standards compliance written into grant language in DHS and almost certainly in DoD, DoT, DoJ, and Commerce (NIST) as well, so I think we need to take advantage of all this mutual leveraging.

One argument for Washington to consider: If we're going to be making these investments, we should make the most of it, and use it the way IT used Y2K. I don't think we can say that its always the case, but it seems to me that the IT community uses a recession to push the limits of technology so that they can claim great new capabilities as the rest of the economy emerges from the pits. You always get the most for your investments during recessions because most of the competition hunkers down and just endures it.

However, one thing I'm really worried about is what we're seeing big time in the Financial Crisis, and that is the slavish misapprehension that BIG problems can only be solved by BIG BOX solutions, e.g. only BIG Companies (that are supposedly TOO BIG TO be allowed to FAIL) can handle BIG problems, when, as the FBI Virtual Case File Fiasco showed, BIG solutions to BIG problems often don't work if those BIG problems are BIG because they are built up of widely distributed smaller problems, spread out nationwide or larger.

Heterogeneous IT systems can't be coordinated easily when interoperability isn't already established. In these cases, BIG companies CAN ONLY FAIL, and we have to avoid that if at all possible.

Unfortunately, getting the folks in power to understand this is going to be very difficult. So we need to include that factor in our solutions. With widely adopted and/or mandated standards, interoperability is possible, but we still need to allow for testing to ensure that systems and applications and webservices actually perform interoperably. This actually represents a tremendous opportunity for startups, but I'd prefer to see existing companies learn how to adapt and keep adapting.

We now have from DHS a NIMS (National Incident Mgt System) Support Center charged with testing for conformance with NIMS mandated standards, e.g. CAP, EDXL-DE, EDXL-RM and EDXL-HAVE. However this effort is in its early infancy. I think it would be good to get NIST involved in NBIMS testing and Sensor testing, since they already have a Sensor Standards Harmonization Group.

Cheers,
Rex

At 9:08 AM -0500 11/26/08, Deborah MacPherson wrote:
Would you say a BIM providing the context is like IFC2x3 bindings? See the MVD group at NBIMS <http://www.blis-project.org/IAI-MVD/>http://www.blis-project.org/IAI-MVD/? Looking forward to reading the links below. 
----------
From: Bob Smith <bobsmithttl@xxxxxxxxx>

Hi,
 
Thanks for including "Breaking Glass" reference. I mentioned that perspective to Deborah a few days ago.
 
Friday or Monday works for me on the BSP call.
 
Yesterday I heard that a Sr. BoA VP was promoting a large green loan package to a city in order to satisfy some financial bailout condition. I brought up oBIX and BIM in that conversation, along with the need to get more transparency in the several multi-million dollar energy efficiency and building performance discussions.
 
Several of us were tasked to develop BSP like performance indicators for the community and its buildings.
 
Interesting resources on the table: $20-30 million, 3 yr to 20 yr time horizons, intent to integrate federal and state environmental criteria into a city's policy==>program===>budgeting==>performance metrics==>[repeat] cycles.
 
Toby, what is happening with your Blue Vision effort? Seems that is what our new city administrator and mayor seek.
 
All of this is confidential and somewhat in flux until after Monday's council meeting announcement.
 
Sounds like events are starting to overtake our plans?
 
Cheers,
 
Bob 


----------
From: Carl Reed <creed@xxxxxxxxxxxxxxxxxx>

Deborah -
 
OGC offices are closed on Friday and I will be on a plane to Europe for next week's OGC meetings. Apologies. I will be in Europe all next week but can call in if the time difference works. I will use Skype.
 
Regards

Carl
 
----------
From: Deborah MacPherson <debmacp@xxxxxxxxx>

Proposed Conference Call:

TITLE: Connecting Building Information with EDXL

Choosing 1 or 2 themes from list below for discussion.

Proposed time: Friday November 28, 3 to 5 EST/ Noon to 2 PST

Host: Peter Yim/Ontolog can accommodate including audio capture (post processing work not included)

Please RSVP debmacp@gmail by Friday 2 EST and will get a web page set up, will send post call in number there later today / by Friday noon EST

Thank you for your interest in this complex subject matter. 

1. Sensor data, GIS data and Building Information Data

- from BIM to EDXL

- Building Information Systems overlapping SensorML from OGC

- The levels of SensorML and oBIX

- MVD, IDM, and IFC

- Security applied to the structures of the BIM

- Situational Reporting specification

2. Visibility and Relationships

- The Smart grid

- Where Building Emergency Response Information fits into EDXL

- Where Emergency Medical Information Systems fit across disciplines and standards groups

- Rendering on tiny devices

- Generating interactive PDF's on the fly

- Excluding data structures

3. Allowing for Testing

- Embedded systems, building systems, power supply and distribution must all change their security model

- learning how to adapt and keep adapting

4. Transparency in multi-million dollar energy efficiency and building performance discussions

- investments during recessions

- large green loan packages

- BSP like performance indicators

- specifying and contracting building service performance requirements

5. Widely distributed smaller problems, spread out nationwide or larger

- Query in context

- Infrastructure planning

6. People who need to be in the conversation

- NBIMS

- OGC

- NIST Sensor Standards Harmonization Group

GIS Subcommittee (EM GIS SC)

Messages and Notification Subcommittee (EM-Msg SC)

- Emergency Interoperability Consortium (EIC)

7. The Building Emergency Response Scenario

- Building Automated Alerts

- Mapping Alerts to Floorplans

- External Alerts

- Incident Assessment

- Communicating with the Building

- Building Source Data Classification

- Fire fighter building features

- Alert event types and related categories

- OmniClass

--
********************************************************


----------
From: Deborah MacPherson <debmacp@xxxxxxxxx>

No worries - there is actually too much to talk about. I just laid out some themes, can tackle only one of them on Friday even if very efficient. 
--

----------
From: Carl Reed <creed@xxxxxxxxxxxxxxxxxx>

Caution, Will Robinson. While excellent use cases are defined and a support infrastructure exists in the US for NIMS related work, the issues and activities related to interoperability and in-building sensors, alerts, and so forth is an international issue. For example Taiwan has a major program related to standards based approaches to deploying, monitoring, accessing, and tasking sensors in the built environment - including alerting. And Korea has another major in-building sensor activity as part of the national u-City initiative.

That said, I agree that testing is necessary. However, setting up a viable, long term compliance testing infrastructure is no easy task - especially one that any organization can self-test an implementation of a standard against.

Regards

Carl
----------
From: Carl Reed <creed@xxxxxxxxxxxxxxxxxx>

I know that the example used in the referenced PR is not for the built environment, but the interoperability demonstration concept - as Rex at. al. have done with the IRSC activity - is valid.

http://spatialnews.geocomm.com/dailynews/2008/nov/26/news3.html

Cheers

Carl

----------
From: Deborah MacPherson <debmacp@xxxxxxxxx>

This is a very big and a very hard problem. From my perspective at this point in time serving on NBIMS committees, the groundwork/framework itself for our mixed up country is the only issue. There are many lessons that can be learned from other countries, especially European bSa efforts - but the US is its own problem in regards to transparent information vs nondisclosure for whatever reason. 

Our whole approach to standards and regulations is different. The enforcement spectrum from California to Texas is huge not to mention tremendous variation in Owner requirements regardless where they are located.

I am extremely skeptical about self-testing, especially with fresh memories of the last 8 years. It does not work for the fox to guard the chickens or for corporations to self-certify compliance to their own definitions for excellence or even what compliance means. There are very few instances where I believe self-testing or certification may be valid. The only one I can think of actually is the army corps self-certifying their sustainability projects to a LEEDS defined level. They are not paying USGBC's endless nickels and dimes and the building will perform but they are self-certifying and self-documenting. This could slip off track within a matter of only a few years or even a few projects. 

STAMP - compliant army housing - NetZero as mandated however the following measurements are excluded..........

I'd rather have fewer standards and compliance tests run by independent organizations because we have too many fluctuations in control over public information here. 

----------
From: Carl Reed <creed@xxxxxxxxxxxxxxxxxx>

Deborah -
 
Understood. I had to make the international statement because occasionally the OASIS EM TC gets extremely US centric - and OASIS is an international standards organization . . . Since I also work for an international standards org, I am very sensitive to the international issue.
 
In terms of the self testing, I should have added that 1.) I am speaking to software interface and encoding standards and 2.) once the implementer feels that their implementation of a given standard passes the tests then a 3rd party needs to vet the results of the test before any stamp of approval is given.
 
Regards
 
Carl
 
----------
From: Rex Brooks <rexb@xxxxxxxxxxxxxx>

Agreed, Deborah,

We should not have the fox guarding the hen house. So let me distinguish between self-testing and self-certification. I am for the former and against the latter. However, the US, for all its difficulties is a great place to test all kinds of things, especially semantics.

The US is in many respects a microcosm of the international community, with the exception that (as Winston Churchill mentioned wrt to US-UK) we are a people divided by a common language.

So, if we can build reproducible solutions based on standards here, the underlying concepts ought to be repeatable in the larger context, at least to some extent.

I think of testing a bit differently as someone immersed in ICT Standards work. In OASIS some TCs have even provided self-testing kits, and I would like to see more of that.  Especially in OASIS, we are tasked with building open (transparent) international standards. This means that our standards, even if the work is partially underwritten by US government agencies, have to face international public review, and we can push past that to ensure that our work is suitable for widespread adoption.

To do that we need to make the standards testable in relatively unequivocal ways so that self-testing, informal and formal testing are all as easy to do as we can make possible. We need this so that, using a US-based example, a vendor can self-test before submitting to a formal certification test which, presumably, would certify not simply the standards-conformance, but the genuine interoperability of a product or service with other certified product or service solutions.

That's also why I'm working on a reference implementation for EDXL-RM and hope to eventually see standards that have ontological representations and reference implementations as well.

Cheers,
Rex


----------
From: Peter Yim <peter.yim@xxxxxxxx>

Deborah,

Note that I changed your directory name ...
( to "ConferenceCall_2008-11-28" from "11.28.08call" )

see: http://ontolog.cim3.net/file/work/BSP/ConferenceCall_2008-11-28/

When you have a chance, you might want to go over this write-up on our
filenaming convention:
 http://community.cim3.net/cgi-bin/wiki.pl?FileNamingConvention

Regards.  =ppy
--

----------
From: Deborah MacPherson <debmacp@xxxxxxxxx>
Date: Wed, Nov 26, 2008 at 3:28 PM
To: Carl Reed <creed@xxxxxxxxxxxxxxxxxx>


Yes I understand. The scope and depth of NBIMS, and the number of pandoras boxes the issues can connect to can be very large. Its a major struggle to stay focused. And yes, certainly agree with all you have said below. 

----------
From: Deborah MacPherson <debmacp@xxxxxxxxx>
Date: Wed, Nov 26, 2008 at 3:39 PM
To: Peter Yim <peter.yim@xxxxxxxx>

Just to clarify on the slides - I made these based upon the scenario written out by NIST. What started this conversation actually was asking permission to use the underlying image which was created by NBIMS and OGC. NBIMS immediately said of course yes, OGC looked at it a little closer and Louis Hecht had some cautionary notes about the difficulties of EDXL and necessity for standards. I responded with a short list of the folks involved so he suggested Carl Reed would like to participate also. So that is where it is now. 

The slides need to be continued as the scenario continues on. The next section is mapping the alerts to building floorplans which is the heart of the matter actually. 

BobSmith and I are trying to set up a meeting with Kimon Onuma at OPS Onuma Planning System who does BIMstorm to try working on these things in BIM and GIS using OPS:
EDXL - you already know what a huge issue this is
Infrastructure Planning - starting with water, my brother in law is an environmental chemist just starting a job with the state of Oregon and will join the meeting as a subject matter expert
Actually I don't have the third item in front of me. 

The point is OPS can export to XML and IFC which is the Industry Foundation Classes that will eventually be what makes BIM work on the largest scales imaginable. So we can try this NIST scenario on a fictitious building, which is provided by David Coggeshell. 

The NIST Building and Fire Research Lab is seeking a standardized way to represent floorplans. At first this confused me because there are many drawing and specification conventions about floor plans and other drawings - they want their own thing and I think I'm getting a better understanding of why they need this very simple view. 

Make sense?

----------
From: Deborah MacPherson <debmacp@xxxxxxxxx>

Thanks Rex = this makes sense and gets it into perspective. 

May I have everyones permission to clean up and forward these emails to BSP list so they may be searched and archived?

Thanks and Happy Thanksgiving!
--

----------
From: Rex Brooks <rexb@xxxxxxxxxxxxxx>

You have my permission and thanks, Deborah,

Cheers,
Rex
----------
From: Deborah MacPherson <debmacp@xxxxxxxxx>

I'll collect all and will do that when ok to be out in the great wide open. 

In the meantime will forward a recent exchange with Alan Vihn NIST BFRL regarding overall goal. 

----------
From: Peter Yim <peter.yim@xxxxxxxx>
Date: Thu, Nov 27, 2008 at 12:36 AM
To: Deborah MacPherson <debmacp@xxxxxxxxx>


Thank you for the detailed explanation, Deborah. Helpful indeed.

Apologies on my misinterpretation ... I was just scanning through the
material, and missed the attribution that the slides are your
work-in-progress (and thought they were from NIST.) Therefore please
ignore my last suggestion (about moving them from the ../file/work/
space to the ../file/resource/ space.) However the naming convention
suggestion is still sound.

All the best to your Friday meeting. Talk to you then.

Regards.  =ppy
--

----------
From: Deborah MacPherson <debmacp@xxxxxxxxx>

thanks peter - NIST BRFL has sent another "underlay" graphic to try. We've been talking about the arrows and some transactions are misrepresented. I'll try their other picture next week and work on the arrows. In the mean time for the call will upload the OGC and the new one from NIST onto the call page. Between choosing a theme for discussion and  those two images, 2 hours will fly, and I'll have the better direction sought to show what the building needs to be smart about. 
--
********************************************************

Deborah L. MacPherson CSI CCS, AIA
Projects Director, Accuracy&Aesthetics
Specifications and Research, WDG Architecture

********************************************************

Attachment: NBIMHierarchicalRelationship.jpg
Description: JPEG image


_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/bsp-forum/   
Subscribe: mailto:bsp-forum-join@xxxxxxxxxxxxxxxx 
Config/Unsubscribe: http://ontolog.cim3.net/mailman/listinfo/bsp-forum/  
Shared Files: http://ontolog.cim3.net/file/work/BSP/ 
Wiki: http://ontolog.cim3.net/cgi-bin/wiki.pl?BuildingServicePerformance    (01)
<Prev in Thread] Current Thread [Next in Thread>
  • [bsp-forum] Fwd: [Fwd: Permission to use image], Deborah MacPherson <=