[
Lists Home |
Date Index |
Thread Index
]
Hello Walter,
As always, it is a great pleasure to hear from you.
I am not sure that I completely understand your points, so if I may, I
would like to lay out in greater detail the notion that I was trying to
make in my document. That way we can concretely examine where we may
agree or disagree.
The scenario that I took in my paper was this: Suppose that an
application is looking for Camera information, and it encounters this
XML document:
<SLR> ... </SLR>
Let us consider the steps the application takes to process the XML
document:
(1) Parse the XML document (this is a syntax issue).
(2) Determine the relationship between "SLR" and "Camera" (this is a
semantic issue). Somewhere the following relationship must be made
known:
(2.1) "SLR" is a type of "Camera".
Once this information is made know to the application it can do
the next (action) step:
(3) If the XML document contains Camera info then do ...
Else do ...
The point that I was trying to make in my paper was:
Should the semantic definition (2.1) be:
(a) hardcoded and buried within each application,
or, should it be:
(b) declaratively stated in a separate document,
using a standard, well-defined vocabulary (i.e., OWL).
I argued for the later, (b).
(I realize that I have not "objectively" stated the alternatives, for
which I apologize. However, that is how I truly see the alternatives.)
Walter, what are your thoughts? /Roger
"W. E. Perry" wrote:
>
> [Last week Roger Costello initiated a discussion of OWL and OWL
> ontologies both here on XML-DEV and also on the RDF-interest list. This
> week he has posted a follow up to RDF-interest but not here on XML-DEV.
> Without wishing to cross-post, I believe that the topic remains of as
> much interest here as on RDF-interest and I am therefore initiating a
> new thread based on my response to Roger on the RDF-interest list.]
>
> "Roger L. Costello" wrote:
>
> > Hi Folks,
> >
> > I have created a few slides to describe, at a high level, the
> > motivation for using OWL:
> >
> > http://www.xfront.com/owl/motivation/sld001.htm
> >
> > Comments welcome. /Roger
>
> Hi Roger.
>
> My very different take on the role of semantics in a universal
> internetwork of complementary and interdependent processes:
>
> We can agree entirely on the headline of your slides #7 and #8:
> "Meaning (semantics) applied on a per-application basis". This is
> precisely how semantics are elaborated: as the outcome of specific
> expertise applied through process. It is, however, in the nature of
> expertise to be idiosyncratic. The most valuable semantics for a given
> purpose are elaborated from the application of the most specific
> expertise. Therefore the 'problem' which you would highlight in your
> slide #9 ('problems with burying the semantic definitions within each
> application') is in fact an inherent property of expert processes. In
> order to apply expertise, processes must comprehend a specific expert
> semantics of the data upon which they operate and the nature of their
> manipulation of that data. In your slide #9 you quite correctly factor
> an application of expert process into code to interpret the data and
> code to process the data. That 'interpretation' of the data is a
> specific instantiation of the particular semantically-freighted
> datastructure upon which a given expert process expects to operate. The
> 'code to process the data' has to be designed for a particular
> instantiation of the data. The more particular the expertise of that
> process, the more particular and idiosyncratic--and less the common
> denominator of a standard semantic vocabulary--must be the instantiation
> of, and therefore the semantics implied by, the data upon which that
> process operates.
>
> Your example on slide #9 of the Mars probe disaster--one application
> interpreted the data in inches, another application interpreted the data
> in centimeters--is actually a counterexample to what you hope to
> illustrate. The cause of the disaster was that different applications
> expected to share *common* semantics: that the data as given was, for
> the purposes of *both* applications, in inches or in centimeters. The
> devastating error was that each application deferred from its own
> expertise to a presumed agreement or 'semantics in common' about which
> *both* applications were fatally mistaken. It does not matter which
> application happened to guess or blithely presume correctly about the
> units of the data as presented. It was an unconscionable abdication of
> the expertise of both applications to make any such presumption. As you
> correctly illustrate on your slide #9, there are two necessary
> components to an expert application, and the first of them is code to
> interpret the data. Part of the application's own expertise is knowledge
> of the units in which it expects to operate, and therefore it is crucial
> for the application to instantiate data in those units for its own
> purposes. And, in turn, crucial to doing that is first recognizing the
> units intended or implied in data as received, in order to elect the
> correct expertise for instantiating data in the units required. The
> usual clues for such recognition or syntactic, which is why I can say
> that in your example you have inferred the line between syntax and
> semantics in the wrong place. An easy case would be if the units were
> explicitly presented in syntax, as with e.g. an inches attribute or a
> units element. Occasionally it is in fact as simple as that, and the
> application can, through its expert interpretation code, readily resolve
> the units presented syntactically into those required semantically. In
> other cases, the application must look at the provenance or structure of
> the data as received and compare it with either or both in previous
> examples that it has encountered in order to make an expert
> interpretation of the data received. The point is that it is always
> incumbent on the application by virtue of its presumed expertise to make
> its independent interpretation of the data received in order to make an
> informed instantiation of the data required. To defer in that necessary
> task of expert processing to some presumed common semantics is to
> abdicate expertise itself, and the predictable outcome is error.
>
> Perhaps we should consider a different example. Suppose that an instance
> of your SLR is presented to an application for customs duty collection.
> The task of that application is not to infer that an SLR is a sort of
> camera but to infer that the particular instance presented is an example
> of dutiable luxury consumer goods. This application is a valuable use of
> the SLR/camera ontology which you are creating, but probably not one
> which you expected, nor one which you have provided 'hooks' for in the
> ontology you are building. Yet our larger purpose here is to build (and
> more abstractly to build the principles for) ontologies distributed
> among processing nodes on a worldwide internetwork. In that effort,
> harnessing the unique perspective and uniquely expert processing at each
> node is the particular value we hope to add by building out the ontology
> to worldwide scale. Clearly the customs application cannot function
> without its own ontological distinctions between dutiable and
> non-dutiable, consumer and industrial goods. Equally clearly we do not
> want to burden every camera hobbyist's SLR ontology with the
> distinctions which are most crucial to the customs agent. The only
> workable way to reconcile those goals, and the only way to build out any
> non-trivial ontology to worldwide scale, is to require as a matter of
> design that semantics are locally elaborated to fill the local needs of
> expert processes. Being local means that these semantics are not shared,
> nor understood in some common way. While it is entirely possible that
> congruent semantics might be elaborated in separate locations by locally
> appropriate processes, the point is not the similarity of the semantics
> but the idiosyncrasy of the processes which elaborate them.
>
> Respectfully,
>
> Walter Perry
>
> -----------------------------------------------------------------
> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> initiative of OASIS <http://www.oasis-open.org>
>
> The list archives are at http://lists.xml.org/archives/xml-dev/
>
> To subscribe or unsubscribe from this list use the subscription
> manager: <http://lists.xml.org/ob/adm.pl>
|
