Re: (Round 2) Proposed Extensions to OWL

A quick note for now...

I was just reading an article about RuleML:

"(RuleML) Transformation rules are also useful for expressing
mathematical functions ..."

This triggered an idea - suppose the we embed a RuleML fragment within
an OWL statement.  The RuleML fragment describes how to transform, say,
miles to kilometers, e.g.,

<owlx:Transform rdf:ID="MilesToKilometers">
      <owlx:tolerance>...</owlx:tolerance>
      <owlx:inputValue>...</owlx:inputValue>
      <owlx:outputValue>...</owlx:outputValue>
      <owlx:inputUnits rdf:resource="#Miles"/>
      <owlx:outputUnits rdf:resource="#Kilometers"/>
      <ruleML:trans>...</ruleML:trans>
</owlx:Transform>

The <ruleML:trans> element contains the RuleML statements which describe
how to transform miles to kilometers.  

Looks promising to me.  What do you think? Does anyone have experience
with RuleML?  /Roger


"Thomas B. Passin" wrote:
> 
> [Roger L. Costello" <costello@mitre.org>
> To: <www-rdf-interest@w3.org>
> Cc: <tpassin@comcast.net>; "Costello,Roger L." <costello@mitre.org>
> Sent: Tuesday, July 08, 2003 1:17 PM
> Subject: Re: (Round 2) Proposed Extensions to OWL
> 
> > Tom, I have read your latest proposal several times.  Let me see if I
> > understand it.
> >
> > The idea is to define an ontology of standard functions.  For example,
> > this defines how to transform miles into kilometers:
> >
> > Standard Functions Ontology:
> >
> > <owlx:Transform rdf:ID="MilesToKilometers">
> >       <owlx:tolerance>5%</owlx:tolerance>
> >       <owlx:inputValue>miles</owlx:inputValue>
> >       <owlx:outputValue>kilometers</owlx:outputValue>
> >       <owlx:inputUnits rdf:resource="#Miles"/>
> >       <owlx:outputUnits rdf:resource="#Kilometers"/>
> >       <owlx:transform>miles = kilometers * 0.62</owlx:transform>
> > </owlx:Transform>
> >
> 
> This is not quite what I was thinking about. The example I gave was for a
> specific instance of a Transform.  In the instance, the inputValue and
> outputValue properties would actually contain the URIs for the corresponding
> resources.  So it would not be
> 
> <owlx:outputValue>kilometers</owlx:outputValue>
> 
> but
> 
> <owlx:outputValue>SomeInstanceOfaLengthValue</owlx:outputValue>
> 
> Of course, with OWL and RDFS you would be able to constrain what kind of
> things are allowed to go into those slots, but I only showed an example of
> an actual instance.
> 
> Furthermore,
> 
> <owlx:transform>miles = kilometers * 0.62</owlx:transform>
> 
> is not quite what I had.   I referred to an (so far imaginary) transform
> resource that I called "G", which was unspecified since I am not clear yet
> how to specify it.  I seriously doubt that we would want to use an unparsed
> string for this.  Anyway, I am fairly sure that we should make the
> transform - or maybe its type -  a resource on its own, so that it can be
> properly characterized.
> 
> > Suppose an application were to receive this document:
> >
> > <River rdf:ID="Yangtze">
> >    <length>
> >       <Length>
> >          <measurement>
> >             <LengthMeasurement>
> >                 <measurementValue>
> >                    <LengthValue>
> >                       <numericalValue>3914</numericalValue>
> >                       <unitSpecification rdf:resource="#Miles"/>
> >                    </LengthValue>
> >                </measurementValue>
> >                <precision>...</precision>
> >                <source>...</source>
> >             </LengthMeasurement>
> >          </measurement>
> >       </Length>
> >    </length>
> > </River>
> >
> > And suppose the application wanted to convert the length data in the
> > document to a value with units of kilometers.
> >
> > The application would "consult" the Standard Functions Ontology for a
> > Transform which has inputUnits = Miles and outputUnits = Kilometers.
> > The transform property then details how to convert the numerical miles
> > value into a numerical kilometers value.
> >
> > Is this an accurate summary of your proposal?  /Roger
> >
> 
> More or less.  The app would have to look up the transform (type) for a
> LengthValue that matched the input and output units.  I say a "LengthValue"
> because maybe for some other kind of measurement, a different transform
> would be more appropriate.  that remains for a more detailed analysis, I
> would say.
> 
>  In addition to computing the conversion, the app would be able to create an
> instance of the transform, similar to my example, and also of the resulting
> LengthValue, and stick those sets of statements back into the data store.
> 
> Everything should be specifiable in OWL except for the actual math part.
> 
> Cheers,
> 
> Tom P

Received on Wednesday, 9 July 2003 06:21:25 UTC