Joe Collins wrote:
> I must admit that I find many of these ontology discussions hard to follow.
> They are too abstract for me.
> (01)
Bear in mind that this is a knowledge engineering exercise. That is a
different software engineering specialty from database design or
distributed systems design or application programming, but the skill may
be useful to the practitioners of those specialties. The product of the
exercise, however, is only useful to those applications that involve
knowledge engineering tools or process knowledge that has been captured
by such tools. (02)
The ontology won't be used in your database, or your database
applications if they are written in Java, but it might be used if you
are trying to design the database or validate your quantity conversion
algorithms. If some SOX rule is interpreted as requiring you to _prove_
that your software gets quantity conversion right, how do you do that?
That is where knowledge engineering comes in. (03)
Welcome to the pragmatics of the 21st century. If you wrote the
software, will the automated vehicle stay on the road? What will it
cost you to ensure your software against the liability of its killing
someone? Or your application against doing serious monetary harm to
some company? Engineers in every other trade have had to deal with such
issues for 100 years. And because of SOX and EU regulations and
household automata, it is finally going to happen to software engineering. (04)
> Let me suggest that we need a set of agreed upon use cases.
> (05)
Good point. One way to characterize requirements. (06)
> How will any UoM knowledge structure be used?
> I believe that use cases will help define and allow some agreement on
>requirements.
> (07)
(1) It will be used by reference, to formally define terms like "30
km/hr" used in other captured knowledge, including databases (i.e., in
formally specifying the interpretation of one or two columns in a table). (08)
(2) It will be used as an "upper ontology" for "microtheories" that
document the details of a particular discipline that involves
measurements, such as the behaviour of a class of medical instruments,
or the design of distilleries or semiconductor fabrication systems. (09)
> What kinds of knowledge do we expect to express?
> Let me suggest these (open-ended) categories:
>
> 1) At a minimum people want to express physical quantities in databases, as
> inputs to and outputs from applications that use this data.
> (010)
This work will have no direct impact on SQL databases and Java
applications. But it will be used in the expression of physical
quantities in knowledge bases (or interpretation of SQL databases by
knowledge conversion tools), and in applications that involve a
"reasoning engine", such as Jena or Prolog, to interpret inputs, outputs
and intermediate evaluations that involve physical quantities. (011)
> 2) Support for units conversion.
> (012)
Indeed. This is a primary concern in making effective applications
based on reasoning engines. (013)
> 3) I have oriented my work towards enabling quantity expression and
>mathematical
> formula expression. This requires some form of mathematical semantics.
> (014)
Yes. This is where knowledge engineering tools typically add
specialized support for basic engineering mathematics. This is one of
the areas in which OWL2 enriches the OWL vocabulary (and adds demands on
supporting reasoners) and in which pure FOL reasoners are very clumsy.
We can define a model, but we probably can't formally define some of the
mathematical concepts it uses -- we will have to take them as
predefined. For example, we will define some elements using terms like
"multiply" and "divide", but we won't define those terms, and we will
doubtless have discussions about precision and accuracy if we don't find
another work and use it. (015)
> N) Reasoning within natural language expressions?
> (016)
I'm not sure what "within" means here, but yes, this ontology would be
involved in interpreting natural language expressions that involve
quantities. (017)
But none of the above is a "use case". These are areas in which we may
be able to find or construct representative and/or interesting use cases. (018)
For example, we may want to support the quantitative concepts in:
In no case shall the diameter of the tank exceed 4.2 metres or the
width of the vehicle bed, whichever is the less.
or
The maximum capacity of a 1200 BTU heating plant in a Zone 4 dwelling
is 16000 cu. ft., where Zone 4 is defined to be a region in which
average nighttime winter temperature is between -5 C and +5 C and the
probability of 24 hours of temperature below -15 C is less than 1%. (019)
That is what I understand to be a "use case". (020)
-Ed (021)
--
Edward J. Barkmeyer Email: edbark@xxxxxxxx
National Institute of Standards & Technology
Manufacturing Systems Integration Division
100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528
Gaithersburg, MD 20899-8263 FAX: +1 301-975-4694 (022)
"The opinions expressed above do not reflect consensus of NIST,
and have not been reviewed by any Government authority." (023)
_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/uom-ontology-std/
Subscribe: mailto:uom-ontology-std-join@xxxxxxxxxxxxxxxx
Config/Unsubscribe: http://ontolog.cim3.net/mailman/listinfo/uom-ontology-std/
Shared Files: http://ontolog.cim3.net/file/work/UoM/
Wiki: http://ontolog.cim3.net/cgi-bin/wiki.pl?UoM_Ontology_Standard (024)
|