RE: RDF datatypes and "magic" properties in CWM

At 12:12 04/10/03 +0200, Leo Sauermann wrote:
>Hi Graham,
>
>I have to admit that I don't understand exactly what your question is
>but I see some things I recognize.

I maybe didn't make it entirely clear that my question was about aspects of 
*implementing* RDF inference, and was aimed particularly towards those who 
have participated in implementing bits of CWM from which I am drawing 
inspiration for my own developingh ideas (this being the designated mailing 
list for discussion of CWM).

I am implementing a toolkit for simple inference in RDF, and I'm finding 
the interaction between RDF datatyping and other deduction patterns to be 
of particular interest.  My hope is that the semantics of datatyping can be 
smoothly and comprehensibly incorporated into a more general scheme of 
inference.

My perception is that CWM does this through "magic" properties (which is 
not intended to be a perjorative term) which certainly addresses one of 
these goals -- handling datatype issues within a broader scheme of 
inference -- but seems to have a less obvious relationship to the 
specification of datatypes in RDF.  For example, the relationship between 
CWM's math:sum and the literal-to-value (L2V) mapping for some numeric 
datatype is unclear.  How does math:sum work when used with xsd:decimals vs 
xsd:integers vs xsd:float?


> > What are alternative viewpoints concerning the role of
> > dataytypes in RDF?
>
> >From my Jena experience I can tell you that the things you are doing are
>sophisticated. In jena/java there is a rulesystem that inferences
>new triples, it has functional features like "sum", "greater than" etc
>you may program more.
>
>Example of rules :
>-> (rdf:type      rdfs:range rdfs:Class).
>[rdf1and4: (?x ?p ?y) -> (?p rdf:type rdf:Property), (?x rdf:type
>rdfs:Resource), (?y rdf:type rdfs:Resource)]
>[rdfs7b: (?a rdf:type rdfs:Class) -> (?a rdfs:subClassOf rdfs:Resource)]
>
>
>The rules are evaluated in Java code that is Datatype sensitive:
>
>Here is the implementation of the "sum" functionality,
>but keep in mind that this is a Java class that is compiled
>and interpretetd by parser/reasoner engine,
>I don't know exactly how this works (Dave Reynolds does, I think)
>
>Interesting code from  com.hp.hpl.jena.reasoner.rulesys.builtins.Sum
>
>             Object v1 = n1.getLiteral().getValue();
>             Object v2 = n2.getLiteral().getValue();
>             Node sum = null;
>             if (v1 instanceof Number && v2 instanceof Number) {
>                 Number nv1 = (Number)v1;
>                 Number nv2 = (Number)v2;
>                 if (v1 instanceof Float || v1 instanceof Double
>                 ||  v2 instanceof Float || v2 instanceof Double) {
>                     sum = Util.makeDoubleNode(nv1.doubleValue() +
>nv2.doubleValue());
>                 } else {
>                     sum = Util.makeLongNode(nv1.longValue() +
>nv2.longValue());
>                 }
>                 env.bind(args[2], sum);
>                 return true;
>             }
>
>
>
>-> So with haskell you seem to have a good way to do it.

My enquiry is not solely about how to do it...  an implementation technique 
to add numbers as above is useful, but feels somewhat ad hoc to me.  I am 
at the point of having assembled a number of underlying primitive functions 
(simple query, back substitution, filtering, substitution modification), 
I'm looking for ways to assemble them to (a) achieve flexibility beyond the 
immediate goals, and (b) also hoping for a form of composition that can be 
related back to the formal semantics of RDF.

For an example of what I mean by (a), consider your implementation of 
summation:  would it be help in when performing backward-chaining of 
rules?  I think not.

For the relationship to formal semantics, I'm thinking along the lines of:
(a) separating lexical-to-value mappings from other relationships on the 
value space of the datatype, and then
(b) providing a way to introduce inference patterns that can be defined in 
terms of well-understood value-space relationships (e.g. as your example 
above is based on well-known properties of Java numbers, which are 
themselves approximations for mathematical formalisms of number.)

In the case of the vehicle capacity example, I have a desire to separate 
specification of the following ideas:
(1) numerals as names for numeric values
(2) arithmetic relationships between numeric values
(3) the properties concerning vehicle capacity being in certain arithmetic 
relations.

Item (1) is quite easily separated:  it seems to me that it's quite clearly 
part of the treatment of a datatyped literal, and I don't think it need 
arise anywhere else.

Items (2) and (3) are the ones I'm still thinking about how to 
separate.  (2) seems to be described quite naturally by a CWM-style "magic" 
property, except that I think such properties should legitimately appear 
anywhere in a graph, and appropriate inferences be available.  Then item 
(3) used in inferences that are related to application domain knowledge.

There may be some justification for CWM's special treatment of properties 
in the antecedent of a rule:  it is the only place where the variables in 
the relation may be regarded as being universally quantified.  When used in 
a simple RDF graph, the terms used in a statement are either fixed URIs or 
bnodes, which are effectively existentially quantified.

Still thinking...

#g


------------
Graham Klyne
GK@NineByNine.org

Received on Tuesday, 7 October 2003 13:20:40 UTC