I cannot disagree with a single one of your arguments. Sooner or
later, deep down in the muck. Some of the “base services” will get
translated into things every bit as concrete as the “concrete aggregate standard”.
Others will get translated into more “airy” things.
Early during my career, I walked by the John Hancock tower in
Boston regularly. Every detail of the materials had been specified; the
aerodynamic properties of the building had not been. At least once a week, a
giant pane of glass would pop off many stories up and float (sic) to the
sidewalk. For the *semantic* project, I don’t want to be
discussing the window caulking…
A 4th of July weekend discussing the idea of building
semantics with commercial building owners in an informal setting convinced me
even more that I want to stay out of the “muck”. The value they saw
as a plus was giving the leasing agent a common way to discuss value delivered,
and to discuss comparative benefits of services provided. If we create this language,
then every commercial owner cares. If this is a common ways for owners to
discuss value, then it becomes a part of the re-sale audit of every building. If
it becomes part of the re-sale audit, then it becomes part of the metric used
to evaluate operations and maintenance. If it becomes part of the re-sale
audit, then it is what every developer wants to discuss during design.
You and I and everyone deep in the BIM world can know that
certain words can map to Masterspec information. Some of the words will not
[yet]. At every meeting, it seems, someone, whether at FIATECH or at BuilConn
will bemoan “but where are the owners?” I envision this as driven
primarily for and by the needs of the owner and leasing agent *first*
and then mapped back, when appropriate, to the dweeb-speak. If we do it the
other way around, we’ll get what we already have.
As you say quite well at the end “sometimes its
people that have a hard time interoperating”.
Thanks
tc
"When one door closes, another opens; but we often look so
long and so regretfully upon the closed door that we do not see the one which
has opened for us." -- Alexander Graham Bell
|
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:
bsp-forum-bounces@xxxxxxxxxxxxxxxx [mailto:bsp-forum-bounces@xxxxxxxxxxxxxxxx] On
Behalf Of Deborah MacPherson
Sent: Tuesday, July 08, 2008 8:48 AM
To: BSP Forum
Subject: Re: [bsp-forum] Bouncing things off the owner
Toby ~ this is a very hard problem and inspiring proposed
solution to at least some part of it. However, I question these phrases:
"These words
will provide a common basis for discussing service between all actors over the
life of the building. They will also provide the groundwork for buildings to
interact with actors external to themselves."
I don't think it is words only, but relationships between them on many levels ~
along with future building models and geographic information including all the
data themselves (for example sensor reports) somehow associated with the
building, its zones, its type, regional conditions and changing global
conditions. Leveraging the common basis requires more than learning technical
dictionaries to build models or collect data, but Owners and public services like
fire departments and environmental boards need tools for going straight to and
assembling parts of the building data as needed. Could be an immediate need
like shutting down air handler 2, could be long term like BobSmiths issues in
Huntington Beach.
"....these semantics will become the basis for interacting with
BIM."
But BIM is also drawings and models, and even radio chips and GPS to know where
a building, including its elements and programs, are located and how they are
(supposed to be) constructed. Wouldn't a future owner like to get the
blueprints and specifications, or check on the performance of a service of the
building by clicking on device, scanning the place/readings/elements, to get
only the data needed to present in simple form? There will always be more
information available than the Owner or local jurisdiction needs. If so,
will this zooming, sorting and prioritizing be done using a keyboard or a
mouse? I think the semantics will be hidden to most users.
Can you please post the entire scenario on the charter as a sample problem?
Incorporating building spaces and system zones into the framework only means
adding OCCS Table 13, Spaces by Function, (based on ISO Table 4.5 Spaces by
function or user activity) and OCCS Table 13, Spaces by Form (based on ISO
Table 4.4 Spaces by degree of enclosure.
If there can be scientific studies and maps of happiness, there can be
a mathematical standard for the comfort index….
"Semantics are the words used to describe things. When similar things
get the same name, we are making semantic decisions."
The difference between "flat paint finish" and "flat concrete
finish" is quickly evident by the first 2 digits of Division 09 vs
Division 06 in MasterFormat. CSI specifications and formats already have a lot
of built in semantics. How should they be used most efficiently and
effectively?
"The concrete basis for value in building services require a common
semantic framework. At the highest level of abstraction, these services slide
into ontology, where the building operator defines value. The building
operator, or even the building designer, must be able to define value, to
define the construction of the top level semantics.
And that is the swing between building service semantics and building
service ontology." should also be added to the charter because it
really explains why.
Thanks for writing that post and including the very strong feedback.
Ontologies do need to work in the real world too. Most of the technology is
already available, sometimes its people that have a hard time interoperating.
Deborah
On Tue, Jul 8, 2008 at 7:39 AM, Considine, Toby (Campus
Services IT) <Toby.Considine@xxxxxxx>
wrote:
I was discussing the
issues of this forum with several large commercial owners, this weekend. I got
some very strong feedback as to what should be in, what should be out, and what
should be left not completely pinned down…
I wrote about it in my
blog
tc
Building service performance is not handled well during building design
because there is currently no accepted way for owners and designers to discuss
the services desired and the performance expected for each service in simple
general terms. Construction processes deliver diverse technical systems each
discussed using concrete physical attributes whose effects are understood
through a deep domain knowledge not often common to either owner or designer,
or even to different contractors. This leads to specifying materials and
processes rather than results, is ineffective in defining success after
commissioning into long term operations and maintenance.
New demands that buildings interact
dynamically with entities other than the owner and operator will soon require
that provisioning of services be managed over the lifecycle of the building
rather than merely for procedural completeness at building turnover. These
external entities include power provision and emergency management. The
transacted power grid will expect buildings to negotiate with remote, local,
and internal energy suppliers to meet the needs of the occupants. Emergency
Management will expect buildings to respond to environmental alerts, i.e.,
tornado warnings, to provide situational awareness after an event.
Over at ONTOLOG, several of us are formalizing new semantics to enable
discussion of building services and their quality. These words will provide a
common basis for discussing service between all actors over the life of the
building. They will also provide the groundwork for buildings to interact with
actors external to themselves.
If we do this right, these semantics will become the basis for interacting
with BIM. Each area of knowledge and practice within the Building Information
Model (BIM) has a formal interface to other areas of the BIM. This interface
allows information to flow both ways. Information flows into an area to define
goals and constraints. Information flows out of an area to provide results and
requirements. This allows for multiple processes within each area. During
design, the goal is to let the owner participate in decision earlier in the
process. Imagine the following scenario.
During design, a six story building is designated as commercial space on
the ground floor, a restaurant on the second, and office space for the next 4
floors. Quality indicators for all three types of space rely on the Effective
Ventilation Index (EVI). Commercial Comfort Index is defined based upon room
temperature, humidity, occupancy, and EVI. The standard for a strip mall is
1.0. The lessee, a high end store, requests that a CCI of 1.2 be provided, and
documented by the underlying systems, and that it be done at a watts/square
foot no worse than industry standard. The restaurant is divided into seating
area, which uses the standard CCI and the catering area, in which a higher EVI
is required by regulation. In the seating, the CCI must take into account the
higher density of sitting customers as compared to the retail space downstairs.
Office space is quite competitive and the local market has high vacancy rates.
The owner wishes to promise Office Worker Alertness index greater if 0.8
(prevailing standard is 0.64) to achieve reduced vacancy in the prevailing
market.
I shared this vision with Bo, a seasoned real estate professional who
remains one of my more skeptical audiences. He vigorously objected. To Bo, a
developer might choose to distinguish itself though having many more air turns
per hour than the competition. They would still want to discuss the value in
the same terms, but would not wish to be held to the same engineered standard
of comfort. Bo vigorously objected to a mathematical standard for the comfort
index….
This threw me for a loop. Then I recalled some spirited discussions from the
Business Process Execution Language (BPEL) groups. BPEL is the language for
passing a work flow or business process around using web services. There have
been spirited discussions about BPEL, including conversations that claim that
BPEL is not useful because business process is the proprietary advantage of any
business, and so therefore real business process will never be passed around.
This seemed to align with Bo's comments.
Let me reprise semantics and ontology how I use these words. Semantics are the
words used to describe things. When similar things get the same name, we are
making semantic decisions. As people, semantics let us discuss the services
provided by a system, and to compare and contrast how well those services are
provided. To systems, semantics create a basis for interoperability and the
creation of Services. Ontology, or meaning, is a way to discuss a value of the
services; ontologies are variable. Crudely, accounting is a semantic system;
cost accounting and financial accounting are different ontologies built upon
common accounting semantics.
If we take this model, than I agree with Bo. The concrete basis for value in
building services require a common semantic framework. At the highest level of
abstraction, these services slide into ontology, where the building operator
defines value. The building operator, or even the building designer, must be
able to define value, to define the construction of the top level semantics.
And that is the swing between building service semantics and building
service ontology.
"There are a thousand hacking at the branches of evil to one who is
striking at the root." -- David Thoreau
_________________________________________________________________
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
--
*************************************************
Deborah L. MacPherson CSI CCS, AIA
Projects Director, Accuracy&Aesthetics
Specifier, WDG Architecture PLLC
**************************************************
|
_________________________________________________________________
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)
|