Dear Matthew and Ed, (01)
I believe that you are both wrong. The curves in
a n-dimensional property space, or the functions
between property spaces, are not the fundamental
objects, but instead artefacts created to present data. (02)
The key object is a space of states, where each
state within the space has many measurable
properties. Examples of such spaces of states are
states of a pump (with different Q, h values) or
states of a material test specimen (with
different times, loads and extensions). (03)
It can be convenient to present the way that the
properties vary with respect to a space of states
as a curve or surface in an n-dimensional
property space or as a function between property spaces. (04)
It can also be convenient to identify each state
within a space by a number, or tuple of numbers,
(i.e. by a parameter space) and to present the
variation of each property separately with respect to the parameter space. (05)
I have referred to a "space of states" rather
than a "set of states", because although there is
a set of states, there is also a topology for the set. (06)
In an instrumentation system, the properties are
recorded for only some states within the space.
It may be convenient to define an interpolation
rule, which predicts the properties at others. (07)
Best regards,
David (08)
At 22:00 12/03/2013, Barkmeyer, Edward J wrote:
>Matthew,
>
>I wrote:
>
> > 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,
>
>
>Matthew wrote:
>
> > MW: There is something called
> multidimensional_property_space which was
> intended to handle things like pump curves.
> Were you aware of that, or have you tried it
> and found it wanting? I’d be interested in
> your experience. The idea would be to specify
> sufficient points from the curve that you were
> happy to interpolate between them.
>
>I understand this thing to be a sequence of
>points in n-space, where each dimension is a
>property. The ontological problem is that that
>is not a curve -- it is a sequence of
>points. In the STEP models, for example, there
>are B-spline curves that are defined by a series
>of inflection points, and that series defines a
>unique curve. The series is defined to be the
>representation of a B-spline, with that
>interpretation of the points. If I specify a set
>of points and require a particular fit algorithm
>for a particular kind of parametrized function,
>that is the definition of a curve. I suppose
>there should be specializations of the general
>multidimensional_property that would clarify
>this, but the idea that it is a sequence of
>points in n-space doesn’t mean much by
>itself. (I would say this is an ontology of a
>representation and not of the concept.)
>
>That said, the sad fact is that a pump curve
>really is just someone's fit to a set of
>actually measured values for particular inputs,
>and the real data is just the pairs (input,
>measured behavior). The fit is indeed in the
>eye of the sender, and if the receiver uses a
>different algorithm and gets a different curve,
>neither of them is necessarily "right" (they are
>just the products of different engineering
>intuitions or skills), and the proof of the
>pudding will come in the pump test. That is,
>the multidimensional_property really is just a
>set of observations. The pump curve is not the
>same kind of thing as a spline curve
>specification for an airfoil, where that shape
>is what will have the desired aerodynamic properties.
>
>-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 4:12 PM
>To: 'Ontology Summit 2013 discussion'
>Subject: Re: [ontology-summit] Hackathon: BACnet Ontology
>
>Dear Ed,
>
>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.
>
>MW: I agree. I meant to say “basic measurement
>data”. The rest of what you say is precisely
>why I said: “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.”
>
>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,
>
>MW: There is something called
>multidimensional_property_space which was
>intended to handle things like pump curves. Were
>you aware of that, or have you tried it and
>found it wanting? I’d be interested in your
>experience. The idea would be to specify
>sufficient points from the curve that you were
>happy to interpolate between them.
>Regards
>Matthew
>
>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 anothher 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/ (09)
============================================================
David Leal
CAESAR Systems Limited
registered office: 31 Shell Road, Lewisham, London SE13 7DF
registered in England no. 2422371
mob: +44 (0)77 0702 6926
landline: +44 (0)20 8469 9206
e-mail: david.leal@xxxxxxxxxxxxxxxxxxx
web site: http://www.caesarsystems.co.uk
============================================================ (010)
_________________________________________________________________
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/ (011)
|