Hans,
(01)
Thank you. I think this is a very useful observation, with respect to
integrating multiple ontologies.
(02)
-Ed
(03)
> -----Original Message-----
> From: ontology-summit-bounces@xxxxxxxxxxxxxxxx [mailto:ontology-
> summit-bounces@xxxxxxxxxxxxxxxx] On Behalf Of Hans Polzer
> Sent: Tuesday, March 12, 2013 8:28 PM
> To: 'Ontology Summit 2013 discussion'
> Subject: Re: [ontology-summit] Hackathon: BACnet Ontology
>
> 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/
(04)
_________________________________________________________________
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)
|