Closer, but it still focus on the services and not on the
performance. To my mind, we only identify the services so we can discuss their
performance; their performance is how we, the owner, and the leasing agent can
describe value.
I suggest the “try the speech out on your dog”
approach. Go to someone not in the design or mechanical engineering trade, and
ask them what CFM means to them, and whether a certain number of CFM would make
their office better. Expect a blank look.
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:58 AM
To: BSP Forum
Subject: Re: [bsp-forum] Mission Statement
How about: "Building
Service Performance" is an Ontolog project to formalize how we describe
services performed in the built environment.
On Tue, Jul 8, 2008 at 7:56 AM, Considine, Toby (Campus
Services IT) <Toby.Considine@xxxxxxx>
wrote:
This is getting closer. Owners,
most owners, do not participate in these decisions because we have made it
about the systems, not the services. Just as Kimon Onuma states in his BIMSTORM
video that the big change is that, for the first time, the owner can ask owner
questions (what will the design changes do to $/SF, and how will it change the
SF?) we want the owner to ask about systems without getting bogged down in
details about contact closures.
In fact, I will make it
stronger. I have no desire to participate in a semantic project to define
details of contact closures precisely. It has already been done, and done well,
with AEX and ISO 15926. It does not change the realities of the
construction bidding market, in services are specified but performance is never
required. It is anti-innovation in an area in which technological change is
required. In other words, it is barely worth doing.
We started the charter with
Building Service **Performance***. The current mission statement does not even
mention performance. This goes suspiciously close to the same old *&^.
I thought Deborah's observation
of the [non]service perspective of the traditional (or even better than
traditional] perspective and how it misses the boat is spot on; avoiding
following into those reflexes will be our biggest challenge.
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
Was just having a similar discussion with Peter
Benson at ECCMA, Deke Smith and Michelle offline - concluded with
"....I'm sure Michelle or Toby and the others could explain better, but
maybe the ontology we are after is is not to enforce top down or bottom up
views for data maintenance, its more to build bridges based upon building services
to the occupants and surrounding community rather than building elements,
jurisdiction requirements, use group etc that drive project delivery in the
first place. Example, daily or even hourly sensor reports versus trends
across a particular region presented in simple graphs rather than large stacks
of detailed reports. It doesn't mean the identities, maps, classes, properties,
units of measure, qualifiers, and values are not there, they are just not
needed up front and visible in this framework for certain users. In other
words, someone could use this open ontology on any level to dial in the words
or values they know and maybe this could help place and locate the rest of the
data they should look at to make whatever decision has them in the building
data in the future after the documents have changed hands 20 times. Like the
phone game, there is a potential for loss and error at every exchange. "
On Mon, Jul 7, 2008 at 2:23 PM, Bob Smith <bob@xxxxxxxxxxxxxx>
wrote:
Hi Deborah,
Toby makes a powerful point, IMO,
that separating services from hardware, or as he puts it "The owner wants
a building system that keeps employees alert (and productive)". The
service is provided by system components. The owner is not concerned with
specifications of all the hardware options, but instead the result or output of
the system. It is up to the specialists to use the owner's statement of service
requirements. Decoupling services from system components requires a change in
mindsets.
I see a huge advantage of this BSP
forum of having generalists and specialists to discuss the problem and how
Ontology provides a new level of thinking.
Do you think it makes sense when
mentioning Frameworks to link to the 2nd Ontology Summit's
Communique dealing with DIMENSIONS of a Framework?
http://ontolog.cim3.net/cgi-bin/wiki.pl?OntologySummit2007_Communique#nid10NG
and the Dimension Map that Peter
Brown and others developed http://ontolog.cim3.net/cgi-bin/wiki.pl?OntologySummit2007_FrameworksForConsideration/DimensionsMap
Often times a building's
"Owner" is a city government, such as the City of Huntington Beach.
Framing a large capital investment project in terms that the citizens can
understand, and allowing the architects, engineers, constructors, and energy
manager deliberate over options for achieving those services raises many
opportunities for improved budgeting and value clarification.
(Of course, some of these topics
are rather removed from our mission and charter, but are implicit in the
discussions).
Cheers,
Bob
In my opinion "related services"
needs to be explained. For example, it was news to some here at WDG that a
"service" of a building could be healthy air the same way the service
of a hotel is a clean bed and restaurant.
If the list of sample services needs to change
or update in the future, that is ok but at least its starts with something and
as the exercises progress, all services listed can be checked just for S&G
just to be sure a sufficient range is covered.
--
*************************************************
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
_________________________________________________________________
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)
|