- From: Graham Klyne <gk@ninebynine.org>
- Date: Fri, 03 Oct 2003 18:43:36 +0100
- To: www-rdf-interest@w3.org
Hi, <background> I've been thinking about how to implement an (extensible) datatype inferencing framework in my Swish software [1]. This is part of a project I started in part because, for example, I couldn't figure out how to do things like IP address testing in CWM [2] (e.g. is address a.b.c.d part of the IP subnet m.n.o.p/24?). Unlike CWM, I've separated the scheme for defining inference rules from the language over which inference is performed -- this led me to using Haskell as my implementation language, as it is sufficiently close to formal specification (pure functional and strongly datatyped) yet provides me with the full power of a programming language in exploring the patterns of inference rule definition. This gives me a lot of flexibility, and begs questions of how [not] to use it. My basic pattern for inference is a query (rule antecedent as query against given graph) which yields a set of sets of variable bindings, which are then back-substituted into the rule consequent to yield deductions that can be merged with the original. I guess this is a common enough pattern. There's a similar pattern for backward-chaining a rule. The "clever stuff" is handled by filtering and manipulation of the variable bindings that result from a query. So, for example, to implement rule 'rdfr1' from the RDF semantics specification [3], I can use an antecedent of the form: ?a ?p ?l . and impose an additional condition on the variable binding that ?l must be bound to a n XML literal, from which the consequent: ?a ?p ?b . ?b rdf:type rdfs:Literal . The "allocated to" aspect of this rule (cf. [3]) is provided by a variable binding modifier that creates a new binding for ?b for each distinct binding of ?l. This is all handled by specific Haskell code. (For the curious, the rule specification in Haskell looks like this: [[ rdfr2 = makeRDFClosureInstanceRule scopeRDF "r2" "?x ?a ?l . " "?x ?a ?b . ?b rdf:type rdf:XMLLiteral ." (isXMLLit "?l") (allocateTo "?b" "?l") ]] ) </background> ... It seems to me that under datatyped interpretations additional entailments are valid, hence additional inference rules can be used. I imagine that for each datatype recognized, there are some additional inference rules one might use. And yet more for cross-datatype inferences when combinations of datatypes are recognized. I'm trying to understand implementation strategies for datatypes in these terms. My understanding of CWM is that datatype-related inferences are accessed by "magic" built-in properties that are used only in the antecedent of a rule. It seems that you thereby have a notation for defining some kinds of inference rule schema; e.g. { :vehicle :standingCapacity ?x ; :seatedCapacity ?y . (?x ?y) math:plus ?z . } => { :vehicle :totalCapacity ?z . } which may be viewed as describing a family of inference rules: { :vehicle :standingCapacity 1 ; :seatedCapacity 1 . } => { :vehicle :totalCapacity 2 . } { :vehicle :standingCapacity 1 ; :seatedCapacity 2 . } => { :vehicle :totalCapacity 3 . } : etc. ... In thinking about this, the questions I ask include: From the basis of experience with CWM implementation, does this seem a reasonable viewpoint? What are alternative viewpoints concerning the role of dataytypes in RDF? Does the above characterization have any bearing on the view sometimes expressed that properties have a somehow more fundamental role in the meaning of RDF? (I ask this because special properties seem to be the key mechanism whereby new "understanding" is added to CWM.) Is CWM able to detect datatype clashes in any circumstances? E.g. the graph: <ex:a> <ex:b> "25"^^xsd:decimal . <ex:b> rdfs:range xsd:string . is unsatisfiable in an {xsd:decimal,xsd:string}-interpretation, because xsd:integer and xsd:string have disjoint value spaces. And if so, what does CWM do about it, if anything? ... My current thinking is that the extension of inference rules might be achieved by functions applied to the variable bindings rather than additional antecedent terms. But I'm still trying to figure out how to abstract out the common idea of (say) '+' applied to numbers. #g -- [1] http://www.ninebynine.org/Software/Intro.html#Swish (This is an old and very basic version of the software. I've added much more but it is, metaphorically speaking, still in bits all over the garage floor, hence in no useful state to publish.) [2] http://www.w3.org/2000/10/swap/doc/cwm.html [3] http://www.w3.org/TR/rdf-mt/#RDFRules ------------ Graham Klyne GK@NineByNine.org
Received on Friday, 3 October 2003 14:11:12 UTC