ontology-summit
[Top] [All Lists]

Re: [ontology-summit] Hackathon: BACnet Ontology

To: "'Ontology Summit 2013 discussion'" <ontology-summit@xxxxxxxxxxxxxxxx>
From: "Hans Polzer" <hpolzer@xxxxxxxxxxx>
Date: Tue, 12 Mar 2013 20:27:58 -0400
Message-id: <031e01ce1f81$9d2edf20$d78c9d60$@verizon.net>
Ed, Deb:    (01)

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".     (02)

Hans    (03)

-----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    (04)

Deb,    (05)

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.    (06)

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.    (07)

-Ed    (08)


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    (09)

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.    (010)

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.    (011)

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.    (012)

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.    (013)


DEBORAH MACPHERSON
Specifications and Research    (014)

Cannon Design
3030 Clarendon Blvd.
Suite 500
Arlington, VA 22201    (015)

Phone: 703.907.2353
Direct Dial: 2353    (016)

dmacpherson@xxxxxxxxxxxxxxxx
Cannondesign.com
Skype debmacp    (017)

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    (018)

Matthew,    (019)

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.    (020)

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.    (021)

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.    (022)

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.    (023)

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.    (024)

-Ed    (025)


--
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    (026)

"The opinions expressed above do not reflect consensus of NIST,  and have not 
been reviewed by any Government authority."    (027)



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    (028)

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.    (029)

Regards    (030)

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/    (031)

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.    (032)



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    (033)

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.    (034)

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.    (035)

Deborah    (036)

Sent from my iPhone    (037)

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.    (038)

Regards    (039)

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/    (040)

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.    (041)



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    (042)

Somewhere in this discussion is a problem that is the essence of what has been 
holding up progress in the facilities domain.    (043)

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.    (044)

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”    (045)

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”    (046)

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.    (047)

DEBORAH MACPHERSON
Specifications and Research    (048)

Cannon Design
3030 Clarendon Blvd.
Suite 500
Arlington, VA 22201    (049)

Phone: 703.907.2353
Direct Dial: 2353    (050)

dmacpherson@xxxxxxxxxxxxxxxx
Cannondesign.com
Skype debmacp    (051)

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    (052)

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.    (053)

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 )    (054)

Simon    (055)

_________________________________________________________________
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/    (056)

_________________________________________________________________
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/     (057)


_________________________________________________________________
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/     (058)
<Prev in Thread] Current Thread [Next in Thread>