Deb,
(01)
I agree with much of what you say. I just want to clarify this:
(02)
> RE: You can't use it to find your cell phone when you set it down somewhere
> on the building site....
>
> The only reason this isn't possible in an occupied building is because
>satellites
> can't see inside to put a blue you-are-here dot onto a floor plan, or in a 3d
> model, as a relative location.
(03)
That is not what I meant. My point was that Google Earth is based on a certain
maximum resolution in satellite photos. You cannot zoom down any finer than
that resolution, and it isn't good enough to see a cell-phone sitting on top of
an oil barrel, even if it were updated in real-time. Next year it might be,
but then it still won’t be good enough to pick up your fingerprints on the
phone. These models are always based on some maximum resolution. They are
simplified by various sampling techniques to produce views of larger spaces on
the same size display, and at some point, a different set of images of the
larger space at an appropriate resolution are substituted, which usually
produces images of the larger space that are better for humans than the
automated reduction of the finer granularity images. (We don't need to get
deeply into image processing. It is just that what you see as "seamless zoom"
is not the effect of a Nikon movable lens. It is an illusion produced by smart
software; the data is discrete.)
(04)
Best regards,
-Ed
(05)
> -----Original Message-----
> From: ontology-summit-bounces@xxxxxxxxxxxxxxxx [mailto:ontology-
> summit-bounces@xxxxxxxxxxxxxxxx] On Behalf Of Deborah MacPherson
> Sent: Tuesday, March 12, 2013 8:20 PM
> To: Ontology Summit 2013 discussion
> Cc: Ontology Summit 2013 discussion
> Subject: Re: [ontology-summit] Hackathon: BACnet Ontology
>
> Hi Ed - lots to think about there. Must ponder further but do need to make a
> distinction between CAD and BIM, where BIM can transfer non-geometric
> data fairly reliably. Even with the notion of location such as room number or
> lat-long that boil down to just text. Hopefully text that is entered or
>recorded
> correctly.
>
> RE: You can't use it to find your cell phone when you set it down somewhere
> on the building site....
>
> The only reason this isn't possible in an occupied building is because
>satellites
> can't see inside to put a blue you-are-here dot onto a floor plan, or in a 3d
> model, as a relative location.
>
> Maybe the problem is trying to get things to work based on either
>
> A) ultra high precision manufacturing tolerances and QAQC tracking
>
> Or
>
> B) clicking on airplane seats on Expedia because there are a finite number of
> plane types to web issue simple backgrounds that can update real time with
> each new seat selection. unfortunately the shape or size of "any" building
> can't be put together on the fly (except point clouds and other huge HUGE
> scanning procedures that are not like united's current fleet)
>
> What is needed is
>
> C) companion model that will be suitable for the overview display
>
> Anyway thanks for the juicy tidtibts to think about.
>
> Deb
>
> Sent from my iPhone
>
> On Mar 12, 2013, at 5:11 PM, "Barkmeyer, Edward J"
> <edward.barkmeyer@xxxxxxxx> wrote:
>
> > Deb,
> >
> > I completely agree. That is what I meant about knowing the intended use
> of the measurements. You can always "zoom out seamlessly" in a CAD
> system, but you can only "zoom in" to the accuracy of the measurements
> provided. The CAD system can produce some really weird results if you
> zoom in to the measurement noise area. So, if you get a model with some
> elements to the nearest cm and others to the nearest mm, you will see
> nonsense when you look at the join at the mm scale. In a similar way, if I
>get
> pressure data for a reduction valve with the process fluid at 20C, it may be
>a
> bad predictor of the pressure behaviors of the same valve when the fluid is
> at 100C.
> >
> > So, yes, if you want to put the building HVAC architecture diagram on your
> cell phone, you have two choices: If you are going to use the same model to
> zoom in and emplace ductwork behind a stairwell, you are going to need a
> measurements model that is accurate enough for emplacing the ductwork,
> and the software that crafts the overview display has to work from that.
>Or,
> you can just have a companion model that will be suitable for the overview
> display, and may be useful for estimating ductwork quantities, but will never
> be used for emplacing equipment. Every model is made to a purpose and all
> models are wrong (by eliminating details unrelated to the purpose). Making
> a model for competing purposes is not easy, and may not be necessary. You
> don't give the mechanics the architect's plan view, and you don't force
> customers to look at plumbing blueprints. The Google Earth model only
> works down to the highest accuracy satellite photos, and those are not
> uniform over all the earth. Google software gives the illusion of much more
> flexibility than is there. You can't use it to find your cell phone when you
>set
> it down somewhere on the building site.
> >
> > -Ed
> >
> >
> > From: ontology-summit-bounces@xxxxxxxxxxxxxxxx
> > [mailto:ontology-summit-bounces@xxxxxxxxxxxxxxxx] On Behalf Of
> > MacPherson, Deborah
> > Sent: Tuesday, March 12, 2013 4:23 PM
> > To: Ontology Summit 2013 discussion
> > Subject: Re: [ontology-summit] Hackathon: BACnet Ontology
> >
> > Yes – all of that –in the manufacturing process tolerances are very
>precise,
> less than the width of a human hair. I’ve seen structural engineer’s be
>very
> concerned over a 2 mm creep in a survey. Many purposes of exchanging
> measurable, modeled, design or production information versus results in the
> real world, as built, do need to be very precise. Both in the models and in
>the
> executed results.
> >
> > However, similar to geospatial being able to zoom in and out apparently
> seamlessly, sometimes using vectors, sometimes using faceted curves and
> points to just look enough like a curve - BIM and mechanical-electrical-
> plumbing systems inside real buildings (which might be specified and
> conform to BACnet), need a way to exchange basic geometries with looser
> tolerances. Just getting a fire fighter to the right room is enough, someone
> renting a studio apartment at XX sq.ft. is not going to get out a laser
>measure
> the way a GSA leasing agent might.
> >
> > GSA does have some rules about “…..agreement on rounding values or
> stating uncertainties”. 95% of all other lifecycle exchange partners
>probably
> could not care less about precision, or even know why a stated uncertainty
> might matter to them outside of the telephone game problem where each
> next retelling changes just a little more and more.
> >
> > To align, up to, 10 models for interaction that would take a building
>layout
> from a digital fire panel, “enlivened” by sensor data, put into a message
>on
> the wire, and displayed on a mobile data computer – is going to need to be
> very generalized curves. That is why the background IE last known
> configuration of a building needs to be static, a PDF or JPG, only the
>location
> of sensor information needs to be dynamic, messages being transported
> over wires only need a “hint” of this measured, modeled, building.
> >
> > DEBORAH MACPHERSON
> > Specifications and Research
> >
> > Cannon Design
> > 3030 Clarendon Blvd.
> > Suite 500
> > Arlington, VA 22201
> >
> > Phone: 703.907.2353
> > Direct Dial: 2353
> >
> > dmacpherson@xxxxxxxxxxxxxxxx
> > Cannondesign.com
> > Skype debmacp
> >
> > From: ontology-summit-bounces@xxxxxxxxxxxxxxxx
> > [mailto:ontology-summit-bounces@xxxxxxxxxxxxxxxx] On Behalf Of
> > Barkmeyer, Edward J
> > Sent: Tuesday, March 12, 2013 2:45 PM
> > To: Ontology Summit 2013 discussion
> > Subject: Re: [ontology-summit] Hackathon: BACnet Ontology
> >
> > Matthew,
> >
> > I have to disagree. Only some measurement data is easy to exchange, and
> even then one must be careful that both the sender and the receiver have a
> common understanding of the nature and purpose of the measurement.
> This includes simple common sense ideas like agreeing on (and documenting)
> the units to be used, or explicitly exchanging units with the numeric
> measurements. It also includes agreement on rounding values or stating
> uncertainties.
> >
> > But there is a lot more to the context of a measurement than just the units
> and the uncertainty. There are standard sizes that have the same name but
> temporal differences in tolerances, and there are considerations like
> operational state and ambient temperature and pressure that affect values
> of the same measurement of the same thing. And finally, like parametrics,
> there are measurement values that are plugged into functions and equations
> to produce other measurement values, and it is very important to agree on
> what those mathematical formulae are. In the particular case of chemical
> processes, semiconductor fabrication, and plastic and metal molding, for
> example, a group of reference measurements is used to specify an observed
> performance curve, while the actual process depends on accurate depiction
> of performance at other points on that curves. Humans often exchange
> these curves as graphs, but software isn’t good at turning PNG images into
> quantitative performance estimations.
> >
> > I know for a fact that this last problem is not solved in 15926, and you
>don’t
> want to open the Pandora’s box that is the relationship between control
> parameters and performance parameters. This is not, in general, a solved
> problem. There are known standard solutions to specific known problems.
> The best guidance is to characterize the measurement information you want
> to exchange in the context of use and look to see whether that problem has
> already been acceptably solved in industry.
> >
> > The important ideas in the VIM are (a) that every quantity (in a use) has a
> ‘quantity kind’ that identifies what quantities it can be compared with,
>(b)
> that no quantity can be known exactly, measurements are comparisons
> against reference quantities of the same kind, (c) that units are associated
> with quantity kinds and are reference quantities for comparisons. The rest
>is
> about what measurement you made, how you made it, and how accurate
> you know your technique to be in that situation.
> >
> > There are many cases in which most of these details don’t matter, because
> both parties to the exchange understand the intent and typical quality of the
> measurement. But there are also many cases in which some of these details
> do matter, because the parties to the exchange have different backgrounds
> and mental models of the situation. The designer of an airflow system and
> the designer of the fans do not have the same model of the problem space.
> They do have models that can be aligned for the purpose of their interaction,
> but they have to be cognizant of the need for that alignment in their
> exchanges.
> >
> > -Ed
> >
> >
> > --
> > Edward J. Barkmeyer Email: edbark@xxxxxxxx
> > National Institute of Standards & Technology Systems Integration
> > Division
> > 100 Bureau Drive, Stop 8263 Work: +1 301-975-3528
> > Gaithersburg, MD 20899-8263 Mobile: +1 240-672-5800
> >
> > "The opinions expressed above do not reflect consensus of NIST, and
> > have not been reviewed by any Government authority."
> >
> >
> >
> > From: ontology-summit-bounces@xxxxxxxxxxxxxxxx
> > [mailto:ontology-summit-bounces@xxxxxxxxxxxxxxxx] On Behalf Of
> Matthew
> > West
> > Sent: Tuesday, March 12, 2013 7:11 AM
> > To: 'Ontology Summit 2013 discussion'
> > Subject: Re: [ontology-summit] Hackathon: BACnet Ontology
> >
> > Dear Deborah,
> > Well if you are trying to exchange measurement data, that is relatively
> easy, and pointing to parametric design examples as having problems for
> standards based exchange, therefore meaning that standards based
> exchange of measurement data is difficult is just plain misleading. You can
> easily exchange measurement data using ISO 15926 for example, or a
> number of other standards, usually labelled SCADA (supervisory control and
> data acquisition). What is not needed is another standard for doing this,
> there are already too many.
> > By the way, measurements look easy from the outside, but once you lift
> the lid, you find all kinds of interesting things there you can easily get
>tripped
> up by – another reason for not reinventing.
> >
> > Regards
> >
> > Matthew West
> > Information Junction
> > Tel: +44 1489 880185
> > Mobile: +44 750 3385279
> > Skype: dr.matthew.west
> > matthew.west@xxxxxxxxxxxxxxxxxxxxxxxxx
> > http://www.informationjunction.co.uk/
> > http://www.matthew-west.org.uk/
> >
> > This email originates from Information Junction Ltd. Registered in England
> and Wales No. 6632177.
> > Registered office: 2 Brookside, Meadow Way, Letchworth Garden City,
> Hertfordshire, SG6 3JE.
> >
> >
> >
> > From: ontology-summit-bounces@xxxxxxxxxxxxxxxx
> > [mailto:ontology-summit-bounces@xxxxxxxxxxxxxxxx] On Behalf Of
> Deborah
> > MacPherson
> > Sent: 12 March 2013 10:11
> > To: Ontology Summit 2013 discussion
> > Cc: Ontology Summit 2013 discussion
> > Subject: Re: [ontology-summit] Hackathon: BACnet Ontology
> >
> > Thanks for the response Matthew. You are probably right on target. The
> thing is some problems and opportunities should not wait. Creating modular
> solutions to keep some information in sets as its transferred would help.
> >
> > Toby and I have been talking about "lighter" versions of our standards that
> are made for heavy monolithic models. What I like about BACnet as an angle
> on this is the transactional nature of collecting and reporting temperatures,
> tasking sensors and so forth that are only one small set of information at a
> time.
> >
> > Deborah
> >
> > Sent from my iPhone
> >
> > On Mar 12, 2013, at 4:46 AM, "Matthew West"
> <dr.matthew.west@xxxxxxxxx> wrote:
> > Dear Deborah,
> > I think the problem, in this case at least, is not quite as you describe.
> > My understanding is that the issue here was around parametrically defined
> objects, where different CAD systems use different parametric functions to
> generate objects from their parametric definition. Because of the different
> functions, to round trip you would have to wrap the parametric description
> so it can be sent to the receiving system, and sent back later. Actually, I
>think
> it would be smarter just to send an identifier that told you the original
>object
> when it came back, but even that does not help you with changes that have
> been made to the object in the receiving system with an incompatible
> parametric system. The problems are just harder than you would think at a
> surface level.
> > Now this is just an inevitable stage of development. In the early stages, a
> thousand flowers bloom, but the vast majority fade. Eventually a few
> remain, and it becomes more important (now these are the survivors) that
> they can interoperate, than that they retain competitive advantage, so
> interoperation is achieved, or a standard developed that customers require
> them to conform to.
> > You can see that the state you are pointing to is in the middle of this
> process. Eventual completion of the process is pretty much inevitable. The
> bad news is that from what I have seen and experienced there is relatively
> little you can do to speed the process up (or slow it down) significantly and
> the time-scale for the process is decades (or more in some cases), not
> months or years.
> > So the smart thing to do is to recognise where you are, try to encourage
> progress through the process, and adopt strategies that recognise the reality
> of where you are in the process.
> >
> > Regards
> >
> > Matthew West
> > Information Junction
> > Tel: +44 1489 880185
> > Mobile: +44 750 3385279
> > Skype: dr.matthew.west
> > matthew.west@xxxxxxxxxxxxxxxxxxxxxxxxx
> > http://www.informationjunction.co.uk/
> > http://www.matthew-west.org.uk/
> >
> > This email originates from Information Junction Ltd. Registered in England
> and Wales No. 6632177.
> > Registered office: 2 Brookside, Meadow Way, Letchworth Garden City,
> Hertfordshire, SG6 3JE.
> >
> >
> >
> > From: ontology-summit-bounces@xxxxxxxxxxxxxxxx
> > [mailto:ontology-summit-bounces@xxxxxxxxxxxxxxxx] On Behalf Of
> > MacPherson, Deborah
> > Sent: 11 March 2013 21:56
> > To: Ontology Summit 2013 discussion
> > Subject: Re: [ontology-summit] Hackathon: BACnet Ontology
> >
> > Somewhere in this discussion is a problem that is the essence of what has
> been holding up progress in the facilities domain.
> >
> > There are ways to publish technical requirements or test for conformance
> online for free, and pay (even substantially) to participate in the working
> groups or have voting privileges. For example OGC, W3C.
> >
> > I can even see being able to own a part name or number within a larger
> communication machine that could be mapped to a generic form for broader
> exchange purposes. For example “13-57 13 15 Dining and Drinking Spaces”
> versus “The Sand Bar and Grille”
> >
> > Depending on the domain, or need for cross disciplinary discussion, many
> on the IP-protected side have no interest in supporting, or will even
>actively
> stops progress, on a common model. There is also the problem of failed
> common models that do not work, will not accommodate different object
> definitions - from software to software or industry model to industry model -
> without loss of data or functionality. Bentley systems has stepped forward in
> this white paper on the IFC model to say actually – the emperor has no
> clothes on. See pages 6 and 7 “Round Tripping”
> >
> > For some reason I think ontologies might be a way these IP-With-Open
> problems might be fixed but maybe I am wrong or wishing for too much.
> >
> > DEBORAH MACPHERSON
> > Specifications and Research
> >
> > Cannon Design
> > 3030 Clarendon Blvd.
> > Suite 500
> > Arlington, VA 22201
> >
> > Phone: 703.907.2353
> > Direct Dial: 2353
> >
> > dmacpherson@xxxxxxxxxxxxxxxx
> > Cannondesign.com
> > Skype debmacp
> >
> > From: ontology-summit-bounces@xxxxxxxxxxxxxxxx
> > [mailto:ontology-summit-bounces@xxxxxxxxxxxxxxxx] On Behalf Of Simon
> > Spero
> > Sent: Monday, March 11, 2013 5:25 PM
> > To: Ontology Summit 2013 discussion
> > Subject: Re: [ontology-summit] Hackathon: BACnet Ontology
> >
> > On Mon, Mar 11, 2013 at 11:53 AM, Peter R. Benson
> <Peter.Benson@xxxxxxxxx> wrote:
> > Deborah, IP is a real issue. We designed the eOTD to try to resolve
> > some of these issues. In a dictionary the IP resides in the
> > representation but also in the identifiers or codes as these are always
> copyright.
> >
> > That is not entirely clear; see e.g. SOUTHCO, INC v. KANEBRIDGE
> > CORPORATION ( http://www.ca3.uscourts.gov/opinarch/021243pe.pdf ),
> > where part numbers were found to be not protected (but see also how
> > Alito takes care to distinguish Delta Dental )
> >
> > Simon
> >
> >
> __________________________________________________________
> _______
> > Msg Archives: http://ontolog.cim3.net/forum/ontology-summit/
> > Subscribe/Config:
> > http://ontolog.cim3.net/mailman/listinfo/ontology-summit/
> > Unsubscribe: mailto:ontology-summit-leave@xxxxxxxxxxxxxxxx
> > Community Files: http://ontolog.cim3.net/file/work/OntologySummit2013/
> > Community Wiki:
> > http://ontolog.cim3.net/cgi-bin/wiki.pl?OntologySummit2013
> > Community Portal: http://ontolog.cim3.net/wiki/
> >
> >
> __________________________________________________________
> _______
> > Msg Archives: http://ontolog.cim3.net/forum/ontology-summit/
> > Subscribe/Config:
> > http://ontolog.cim3.net/mailman/listinfo/ontology-summit/
> > Unsubscribe: mailto:ontology-summit-leave@xxxxxxxxxxxxxxxx
> > Community Files: http://ontolog.cim3.net/file/work/OntologySummit2013/
> > Community Wiki:
> > http://ontolog.cim3.net/cgi-bin/wiki.pl?OntologySummit2013
> > Community Portal: http://ontolog.cim3.net/wiki/
>
> __________________________________________________________
> _______
> Msg Archives: http://ontolog.cim3.net/forum/ontology-summit/
> Subscribe/Config: http://ontolog.cim3.net/mailman/listinfo/ontology-
> summit/
> Unsubscribe: mailto:ontology-summit-leave@xxxxxxxxxxxxxxxx
> Community Files: http://ontolog.cim3.net/file/work/OntologySummit2013/
> Community Wiki: http://ontolog.cim3.net/cgi-
> bin/wiki.pl?OntologySummit2013
> Community Portal: http://ontolog.cim3.net/wiki/
(06)
_________________________________________________________________
Msg Archives: http://ontolog.cim3.net/forum/ontology-summit/
Subscribe/Config: http://ontolog.cim3.net/mailman/listinfo/ontology-summit/
Unsubscribe: mailto:ontology-summit-leave@xxxxxxxxxxxxxxxx
Community Files: http://ontolog.cim3.net/file/work/OntologySummit2013/
Community Wiki: http://ontolog.cim3.net/cgi-bin/wiki.pl?OntologySummit2013
Community Portal: http://ontolog.cim3.net/wiki/ (07)
|