How to define physical rules?

Legacy questions from answers.semanticweb.com
#1

Hello, I want to calculate the energy costs to heat ice to water with a rule based engine. I don’t know which technology to use, because all the rule based tutorials only show father of father of child is grandpa of child examples.

I would want to calculate something like this.

Energy consumption of heating ice from -5°C to 10°C water.

With rules like this:

Ice can exist −273,15°C to 0°C

Water can exist 0°C to 100°C

ice with 0°C can be changed to water with 0°C but that costs 334kJ

heating ice 1°C costs 1.7kJ

heating water 1°C costs 4.2kJ

Can that be calculated with owl? Can someone suggest me a good tutorial? Maybe only a good keyword to search for it?

What's the best choice to do calculations like this?

#2

This is kind of like saying, "I'd like to use JSON to launch a rocket to the moon". It might be possible to use JSON to solve some of the problem, but you're going to need a lot more than just JSON... a splash of nitrous oxide would come in handy.

OWL might be useful to describe a compound (i.e. in this case, water), its melting and boiling points, the latent heat required for phase transitions, and its specific heat capacity, but it's not especially suited for doing actual calculations.

To start with, OWL reasoning never increases the number of terms in a graph. For example, if I have input data which describes only Alice and Bob, then OWL reasoning might be able to figure out different relationships between Alice and Bob, but it will never discover a new individual Carol who was not mentioned in the input data.

This makes OWL unsuitable for mathematical calculations, especially involving real numbers, as they are infinitely many, so they could not all be included in the input data.

OWL doesn't really have any built-in mathematical operators, except perhaps datatype restrictions which will give you "less than", "more than" and "equal to".

So, by all means use OWL to describe your problem domain, but use something more capable to do your actual calculations. Other rules languages such as Notation 3 and RIF might be up to the task, but why not use a real programming language? ECMAScript, Perl, PHP, Python, Ruby, etc...

#3

It's possible to do math in OWL, in the same sense that you can do math with matchsticks or pennies. On the other hand, it's not possible to do math in OWL in a natural way that enables many applications such as decision support.

You see so many examples about family trees because OWL is really good at those kind of problems... Just look in an algorithms book about how to do transitive closure and you might think it's worth the bother of dealing with the warts in RDF tools.

Now, there are constraint languages and things like TK Solver, and you might be able to bolt something like that onto a triple store, the way that Notation 3 bolts first-order logic onto RDF, but that's a big topic.

You could, however, use SPARQL to do calculations. For instance, if you have

  :situation1 a :thermalProblem ;
       :startTemperature 0.0;
       :endTemperature 7.5;
       :material :LiquidWater .

:LiquidWater :meltingPoint 0.0;

:boilingPoint 100.0;

:heatCapacity 4.2;

:heatOfFusion 334 .

then you could write this in SPARQL

  SELECT ?situation,(?endTemperature-?startTemperature)*?heatCapacity) {
      ?situation :endTemperature ?endTemperature .
      ?situation :startTemperature ?startTemperature .
      ?situation :material ?material .
      ?material :heatCapacity ?heatCapacity .
  }

This is an "inference rule" that solves a particular kind of problem. You could write a more elaborate data model and SPARQL query that solves problems that involve 1 or 2 phase changes, which will certainly cover problems of this type that turn up in a physics class. A query that can do problems that involve an arbitrary number of phase changes (think all of the strange magnetic phase transitions that happen at high and low temperatures or the many allotropes of Plutonium) is probably possible

The SPIN language lets you define rules with SPARQL queries that can be implemented with backwards or forward chaining. Many people are discovering that SPIN can when OWL can't.

#4

Here's a start:

:Water a owl:Class .
:Water rdfs:subClassOf [ owl:cardinality 1 ; owl:onProperty :celciusTemperature ] .
:celciusTemperature rdfs:range :CelciusTemperature .
:CelciusTemperature a rdfs:Datatype ; owl:onDatatype xsd:decimal ; owl:withRestrictions [ xsd:minInclusive -273.15 ] .

:WFreezingCelciusTemperature a rdfs:Datatype ; owl:onDatatype xsd:decimal ; owl:withRestrictions [ xsd:minInclusive -273.15 ; xsd:maxExclusive 0 ] .

:WLiquidCelciusTemperature a rdfs:Datatype ; owl:onDatatype xsd:decimal ; owl:withRestrictions [ xsd:minInclusive 0 ; xsd:maxExclusive 100 ] .

:WVapourCelciusTemperature a rdfs:Datatype ; owl:onDatatype xsd:decimal ; owl:withRestrictions [ xsd:minInclusive 100 ] .


:Ice owl:intersectionOf ( :Water [ owl:someValuesFrom :WFreezingCelciusTemperature ; owl:onProperty :celciusTemperature ] )

:LiquidWater owl:intersectionOf ( :Water [ owl:someValuesFrom :WLiquidCelciusTemperature ; owl:onProperty :celciusTemperature ] )

:WaterVapour owl:intersectionOf ( :Water [ owl:someValuesFrom :WVapourCelciusTemperature ; owl:onProperty :celciusTemperature ] )


:WetThing1 a :Water ; :celciusTemperature "-14.5"^^xsd:decimal .
:WetThing2 a :Water ; :celciusTemperature "42"^^xsd:decimal .
:WetThing3 a :Water ; :celciusTemperature "104.3"^^xsd:decimal .

Implies

:WetThing1 a :Ice .
:WetThing2 a :LiquidWater .
:WetThing3 a :WaterVapour .

But yeah, for numeric classifications, OWL 2 could work. For numeric calculations, OWL might not be the best choice.