W3C home > Mailing lists > Public > public-rif-wg@w3.org > July 2007

Re: [Arch] ACTION-259 Start OWL/RDF compatibility section of Arch document

From: Axel Polleres <axel.polleres@deri.org>
Date: Wed, 04 Jul 2007 13:43:21 +0100
To: Jos de Bruijn <debruijn@inf.unibz.it>
Cc: Dave Reynolds <der@hplb.hpl.hp.com>, RIF <public-rif-wg@w3.org>
Message-id: <468B95E9.7070903@deri.org>

Jos de Bruijn wrote:
>>>>>What we cover is well defined.  We cover simple entailment, RDF
>>>>>entailment, and RDFS entailment.  See [1].
>>>>
>>>>As I said in [*]
>>>>
>>>>(a) I don't think we need claim that the rules perform simple entailment
>>>>at all;
>>>>
>>>>(b) I would rather that we defined one or more rulesets and make those
>>>>rule sets themselves the specification of what is covered. I.e. they are
>>>>not "implicit" but "explicit". In particular, different RDFS
>>>>applications typically make use of different subsets all of which are
>>>>easily handled by rules. We would bless a couple of standard rule sets
>>>>(giving them standardized URIs so that importing of those rulesets can
>>>>be hardwired into RDF-aware RIF processors).
>>>
>>>I must say that I do not really like this approach, because it is hard
>>>to know what is going on exactly if we just give some rule sets which
>>>define some kind of semantics for RDF.
>>>Furthermore, the RDF specification defines three normative kinds of
>>>entailment.  I would say that they are normative for a reason; we should
>>>not ignore the specification.
>>
>>we shouldn't, but it might make sense to define some rulesets which e.g.
>>do not include all the infinite axiomatic triples.
> 
> 
> We can certainly demonstrate some cases in which these axiomatic triples
> are not necessary for reasoning.
> 
> 
>>Apart from that, what you write in [1] pretty much makes sense to me,
>>We could summarize what we seem to agree so far as follows:
>>
>> - treat bnodes in a head by skolemization (or the built-ins suggested).
> 
> 
> I assume you refer to the heads of N 3-like rules?
> It is, at the moment, not entirely clear to me how they should be treated.
> 
> 
>> - treat bnodes in a body or query as (special) variables.
> 
> 
> Right.
> 
> 
>> what yet seems to be open for me is three things:
>>
>> - how we'd deal with bnodes in N3 like rules reused in several rules.
>>     Alternatives: - forbid
>>                   - standardize apart upfront.
>>                   - other ... ?
> 
> 
> I am not sure what you mean with "apart upfront" .  

I mean "standardize apart" = "disambiguate by renamiing"

> I have no idea why
> we would want to forbid their reuse.

What is the semantics/scope if they are realy reused?
An existential variable in a rule body is scoped existentially over the 
rule, not over the ruleset.
The semantics of "reuse" would be very unclear to me, and I don't know 
whether we'd want that. Imagine:

  _:a p o.
  s q o. :- _:a q o.
  _:a r o. :- ?x q o.

Is the _:a the "same" blank node in all three cases, or treated differently?

> the question is really whether bnodes with the same name in different
> rules refer to the same thing, or not. I rather hope the latter.

yes, so we'd agree the above would be equivalent to:

  _:a p o.
  s q o. :- ?a q o.
  sk(?x) r o. :- ?x q o.

???

>> - how we'd deal with bnodes occurring in both head and body of N3 like
>>   rules.Alternatives: - forbid
>>                       - treat both as variable
>>                       - treat hewad as skolem and body as variable
>>                       - other ... ?
> 
> 
> Again, I hope they are interpreted differently.

That is fair enough in my opinion.

>> - how we'd deal with results of rule(set)s? ie. if we have a frame
>>   s[p->o] in the head of a rule (where s,p,o is a variable skolem
>>   term, literal, iri, etc), it might well not be a valid RDF
>>   triple, so my question is, for N3 like rules, how would we ensure
>>   that the result is getting back to RDF again. Do we need/want that?
>>
>>   (Here, e.g. SPARQL takes the approach
>>   to simply ignore all non RDF triples, and only consider valid RDF
>>   triples as consequences)
> 
> 
> Here, again, SPARQL uses an ugly syntactic means for getting rid of
> non-well-formed RDF: triples with literals or bnodes in inconvenient
> places are simply discarded. I would argue that we do not want any such
> arbitrary filtering in RIF.

Hmmm, but what's the alternative?

> In any case, I do not think it is up to this working group to decide how
> people should construct RDF graphs from query answers obtained using
> rules exchanged with RIF.

If we see the interoperation with RDF only one-way then yes, but I am 
not sure whether all of the WG like that (I myself would, apart from 
possible technical difficulties love to have the possibility to export 
rules results/models/inferred atoms back to RDF)

best,
axel


-- 
Dr. Axel Polleres
email: axel@polleres.net  url: http://www.polleres.net/
Received on Wednesday, 4 July 2007 12:43:38 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:33:39 GMT