This is an archive of an inactive wiki and cannot be modified.

RIF rules should be able to call out to external query processors

Full Statement

The condition language fragment of RIF should include an extensible mechanism by which rules can consult external "blackbox" information sources or query processors.

It should predefine a core set of such external consultation constructs though others can be added in extensions.

That core set should include:

Extensions or other core candidates include:


  1. This mechanism must identify the nature of the black box in a form which can in principle be interchanged. For a SPARQL source this requies us to identify the specific source, which requries the URL of the SPARQL endpoint and possibly metadata on whether the endpoint supports soap or http bindings for the SPARQL protocol. For external processors such as reasoners then the identification may be a community-agreed label for a class of processors (such as an OWL/DL compliant reasoner) but multiple endpoints or local resources may be used to satisfy the binding.
  2. In the case of an external query this mechanism might take the form of an interpreted-predicate in which one argument is the specification of the information source and the other argument are bound-to/unified with the query results. In the case of an external processor such as an OWL/DL reasoner then a set of predicates might be identified as DL-predicates. The association of these DL-predicates with a specific (class of) processor and OWL ontology would ideally be done by means of metadata annotation or a ruleset-wide declaration rather than an additional argument to the interpreted predicate. However, this is just syntactic sugar.
  3. Note that this mechanism is necessary but not sufficient for RDF integration. SPARQL query on its own does not provide the tightness of coupling needed for RDF deduction rules. It is neither necessary nor, perhaps, sufficient for OWL integration. This is one means by which RIF rules and OWL might be integrated but is not sufficient to implement all such integrations. It only supports the entailment type of OWL to Rule integration (as opposed to Single Model, terminology taken from de Bruijn et al). The working group has to decide whether to specify additional mechanisms.

Position in the DC structure


list (by names) other DCs that depend on that one or on which it depends


Where does this design constraint come from? E.g. the charter, one or more of the already published UC, one or more of the rule systems listed in RIFRAF, an UC not covered in the current version of UCR


RIF without that is of limited use for me




AlexKozlenkov: Anything ranging from information integration scenarios to notification frameworks depends on the database and RDF integration.