Re: RIF must cover RDF triples as data

Christian de Sainte Marie wrote:
> 
> Dave Reynolds wrote:
>>
>> [[[
>> *RDF Data*
>>
>> RIF must cover RDF triples as data where compatible with Phase 1 
>> semantics.
>>
>> Specifically:
>>
>> o RIF MUST provide a mapping from bNode-free RDF statements to RIF 
>> facts so that RIF rules can be applied to (data derived from) RDF fact 
>> bases. This MAY be a "natural" mapping in the sense that RDF facts are 
>> mapped to ground instances of unary and binary RIF predicates or MAY 
>> be based on a "holds" predicate.
>>
>> This mapping will support the derivation of new RDF statements (i.e. 
>> bNode-free RDF statements can be made in the head of rules).
> 
> I think that this is what confuses me. Granted, since some rules 
> interchanged in RIF will apply to RDF data, such rules may contains 
> statements that RDF triple XYZ holds, as a condition or as a conlusion 
> of a rule; and thus, such statements need be representable in RIF 
> (covered). Granted, they could be mapped in various way (btw, why isn't 
> embedding RDF/XML an option?).

If you mean "embed RDF/XML as a means to convey facts in a RIF document" 
then not only is it an option but I've already proposed a start in that 
direction by suggesting we use RDF/XML as the top level rule syntax.
[Any other reactions to that suggestion BTW?]

If you mean "make sure RIF can query over XML data and then let RDF just 
be another case of XML data" then that won't work. There are many ways 
the same set of assertions at the RDF level can get translated to 
RDF/XML, so XML syntax-level access is not good enough for working with 
RDF data. That's one reason we needed SPARQL and couldn't just use XQuery.

> But I do not understand what using a "holds" predicate would add (I 
> guess it is related to the semantics of a RDF triple, but how?).

Dan has covered this already I think but just to make sure ...
If we allow syntactically higher order rules then we can have a 
"natural" mapping such that a RIF atom:

     rdfs:subClassOf(?a, ?b)

would match an RDF fact such as:

    eg:classA rdfs:subClassOf eg:classB .

The issue is that in writing rules for processing RDF we sometimes need 
to be able to use a variable in the predicate position of an RDF triple. 
A "holds" predicate is just one way to enable that in RIF. Another would 
be to make RIF support hilog-like syntactically higher-order rules but 
that might be beyond phase 1. I was trying to phrase phase1 requirements 
here.

> And, above all, I do not understand the statement: "this mapping will 
> support the derivation of new RDF statements". Why should RIF regulate 
> what is allowed in the rules? 

Surely RIF regulates what can be expressed in RIF rules. This limits 
what rules can be translated to RIF. These are all statements about 
RIF's coverage, not constraints on what RDF rule language designers 
might want to do outside of a RIF-compatible subset.

> Phase 1 semantics will allow atoms in the 
> head, so atoms mapping to RDF statements will be allowed by RIF, if we 
> have such a mapping. Whether or not there exist rule languages that are 
> able to handle such rules is a different question (but if no such 
> language exist, where would such rules come from? I mean, who would 
> produce them?).

There are plenty of such languages; and yes this requirement is 
trivially satisfied.

I phrased the requirement this way because early on in the WG there were 
concerns that if one allowed unrestricted RDF in the head of a rule that 
would cause difficulties. This is because RDF includes the notion of 
bNodes which have the semantics of existentially quantified variables. 
Allowing existential variables in the the head of rules would put RIF 
outside horn and outside many current rule languages. There was 
discussion at the time along the lines "just allow RDF in the body then 
and worry about RDF in the head in phase 2+". I wanted to be clear that 
at least RDF-without-bNodes is, as you say, a non-issue and should be 
covered in phase 1.

>> o RIF MAY extend this mapping to include RDF statements involving 
>> bNodes. At this point the working group reserves the right to defer 
>> bNode handling to phase 2, to limit bNode usage to rule bodies only or 
>> to approximate bNode semantics though the use of skolem constants.
> 
> Again, why wouldn't bNodes be allowed where they are compatible with 
> phase 1 semantics (if there are such places)?

That's the issue. What I'm trying to do here is to phrase the 
requirements in such a way that it is clear that we can minimally meet 
them while leaving us some design freedom.

If I said "RIF will allow unrestricted RDF in rule bodies" or some such 
equivalent then people might object that handling bNodes *properly* is 
hard, beyond horn and not part of phase 1.  If I said "we'll ignore 
bnodes completely then" we'd be limiting our design freedom too much. In 
particular several current RDF rule systems essentially treat bNodes as 
skolem constants and this seems to be a useful and practical approach - 
even if it is not identical to the formal semantics it is arguably what 
people actually need. I wanted to leave us the *option* to use this 
approach (and the option to dodge bNodes altogther within phase 1 if it 
is too controversial).

>> o RIF MAY define an external predicate that will enable RIF rulesets 
>> to query web-based SPARQL datasources.
> 
> You mean, using SPARQL queries to specifiy the range of rule variables 
> when the rules are intended to apply to RDF data sources, for instance?

Sorry, I don't quite follow that. Care to expand?

Cheers,
Dave

Received on Wednesday, 11 October 2006 09:38:36 UTC