That must be why I want one (01)
Deb (02)
Sent from my iPhone (03)
On Mar 12, 2013, at 8:27 PM, "Hans Polzer" <hpolzer@xxxxxxxxxxx> wrote: (04)
> Ed, Deb:
>
> This same line of thinking applies to the scope of applicability of
>ontologies themselves. If you view an ontology as a model or representation of
>some portion of conceptual reality, it is essentially the same kind of thing
>as a CAD model, albeit the CAD model might be viewed as a much more
>constrained model than most ontologies. So ontologies are multi-dimensional
>"surfaces" (presumably closed) in an n-dimensional concept/scope space. They
>may intersect along some (or none) dimensions in that concept/scope space,
>just like some CAD models overlap each other, but may not be completely
>aligned along some dimensions (like level of dimensional precision, or
>inclusion of dynamic or material properties). Having a CAD model or ontology
>advertise its concept/scope assumptions via such an n-dimensional concept
>space would allow reasoning about areas of compatibility between diverse CAD
>models or ontologies, and areas where the results of such interaction might be
>"unpredictable" or "indeterminate".
>
> Hans
>
> -----Original Message-----
> From: ontology-summit-bounces@xxxxxxxxxxxxxxxx
>[mailto:ontology-summit-bounces@xxxxxxxxxxxxxxxx] On Behalf Of Barkmeyer,
>Edward J
> Sent: Tuesday, March 12, 2013 5:11 PM
> To: Ontology Summit 2013 discussion
> Subject: Re: [ontology-summit] Hackathon: BACnet Ontology
>
> 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/ (05)
_________________________________________________________________
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)
|