W3C home > Mailing lists > Public > www-rdf-interest@w3.org > June 2003

RE: Proposed extensions to OWL?

From: Danny Ayers <danny666@virgilio.it>
Date: Mon, 16 Jun 2003 11:21:17 +0200
To: "Thomas B. Passin" <tpassin@comcast.net>, <www-rdf-interest@w3.org>, <costello@mitre.org>
Message-ID: <BKELLDAGKABIOCHDFDBPMEPGDAAA.danny666@virgilio.it>

> I do think you might be able to use a DAML-S SimpleProcess, but there are
> two things about doing so -
> 1) It is not the right concept, since the relationship between
> units is not
> really a process.
> 2) DAML does not have a vocabulary for describing the actual
> transformation
> itself (like units-cm = 2.54*units-inch).  So we still have to invent an
> ontology for it and some machinery for making it work, even if we do use a
> DAML SimpleProcess description.  If we have to do that anyway,
> why not take
> the next step and create a vocabulary for the purpose, one that could be
> extended to more complicated transforms in the future?

I'm not sure how better to describe the relationship though - I mean, what
have we got? The human understanding units-cm = 2.54*units-inch and the
mathematical tokens/operators. Although we could build up a vocabulary of
operators that could be used in RDF, I don't think this is really the right
approach, as we already have ways of expressing the operators in programming

> I say SimpleProcess instead of AtomicProcess just because the
> current DAML-S
> draft says that an AtomicProcess must be grounded, but not a
> SimpleProcess.
> Since we are describing an abstract transfomation rather than a service, I
> think that SimpleProcess fits best.

That makes sense (I'll need to read the spec again before commenting

> > An alternative might be simply to include the appropriate bit of Python
> (or
> > whatever) in a literal, with a predicate something like
> 'applyThis'. This
> > sounds quick and dirty, but if the language used is well
> defined, then it
> > should be possible for the whole thing to be (formally) well defined.
> >
> I do not think that this will let a processor discover that two different
> statements that use different units refer correctly to the same quantity.

Hmm, the question is do you merely want to test a one-off equality or
generate a value for potentially any variable?

What about something like :

MyTest argument1 X
MyTest argument2 2.54
MyTest result Y
MyTest processor Python
MyTest algorithm "Y == arg1 * arg2"
MyTest truthValue Z

> It _will_ let the processor figure out how to make a conversion (which I
> suppose could then be checked for consistency, but that can be
> tricky), but
> I do not think that is what we are really after here.  If we go and invent
> the vocabulary and machinery to do this, we might as well just do the real
> thing instead.

I'm not entirely sure what you mean by the last sentence here.

I must admit I'm also not entirely sure of the value of being able to
express this particular kind of equivalence/operation (like units-cm =
2.54*units-inch) in the first place, I would have expected the role of OWL
to express just that it was a "units conversion operation" and to help
locate a service that could deal, rather than handling any operation itself.

Let me ramble through a scenario : a hotel's heating system control. At this
point in time it may well be run by a microcontroller doing fuzzy logic,
with some proprietry system for remote monitoring. Now put it under semweb
control. Each room has a temperature sensor, which is polled every ten
minutes by a microcontroller (with embedded web server) and the result made
available via a http get :


This URI is in turn polled by a monitoring app, which generates an RDF/OWL
snapshot of the hotel's heating's current state.

_:123 room 101
_:123 temperature 30

This is sent to a remote service (fronted by yet another http server) which
passes the data to a fuzzy logic subsystem, which returns a message which
tells the heating system what to do :

_:123 room 101
_:123 facility airConditioner
_:123 targetState OFF

This is sent back to the hotel's URL as a http post.

Now here the RDF parcels are purely descriptive (as we'd expect) but the
service receives one parcel and returns another. Would we expect the process
or/service in this scenario to do the processing directly on OWL-represented
data? I don't think so. But we might want to use OWL for sanity-checking
(validation). We also might want an OWL processor to watch out for
'interesting points of information' in the data being passed back and forth.
If part of the data is outside of certain limits, or fails validity checks
then we want this info pumped down an RSS 1.0 feed to the engineers.

I think this is a reasonable scenario, with an 'internal' OWL processor
doing forward-chained reasoning on the data, but with the sums being done by
an 'external' processor. Although I'm sure there will be occasions when the
use of arithmetic-style comparisons will make things easier, I think
generally speaking arithmetic and other such stuff should be left to the
tools that do it best. What do you reckon?

Received on Monday, 16 June 2003 05:24:39 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:44:42 UTC