Re: SWC review

Chris, thanks for the comments. Replies in line.

Chris Welty wrote:
> 
> 
> REview of http://www.w3.org/2005/rules/wiki/SWC from 11/8/08
> This constitutes a review only of sections 1-3.  I'm actually supposed
> to review rdf:text.
> 
> I fixed a few typos directly in the text.
> 
> ---
> Section 3 intro contains this example:
> 
> _:x ex:hasName "John" .
> Forall ?x ?y ( ?x[rdf:type -> ex:named] :- ?x[ex:hasName -> ?y] )
> Forall ?x ?y ( <http://a>[<http://p> -> ?y] :- ?x[ex:hasName -> ?y] )
> 
> |=
> 
> Exists ?z ( And( ?z[rdf:type -> ex:named]  <http://a>[<http://p> -> ?z] ))
> <http://a>[<http://p> -> "John"]
> 
> 
> However, the second conjunct in the exists is not entailed.  The
> following is:
> Exists ?z ?y ( And( ?z[rdf:type -> ex:named]  <http://a>[<http://p> ->
> ?y] ))
> 
> But in face of the ground formula, it seems superfluous, unless you want
> to make a point about existential generalization.  I'd suggest:
> Exists ?z ( ?z[rdf:type -> ex:named])
> <http://a>[<http://p> -> "John"]


Thanks for spotting this.
I followed your suggestion.

> 
> 
> ---
> Section 3.1.3 Datatypes and Typed Literals
> 
> "When checking consistency of a combination < R,S> or entailment of a
> graph S or RIF formula φ by a combination < R,S>, the set of considered
> datatypes is the union of the set of RIF-required datatypes and the sets
> of datatypes used in R, the documents imported into R, and φ (when
> considering entailment of φ). "
> 
> and then later: "There may be datatypes used in an RDF graph in the
> combination that are not included in such a datatype map. "
> 
> I think this requires more explanation, it simply begs the question why
> aren't the dataypes in S part of the considered ones & the datatype

This is because in RDF D-entailment, not all datatypes need to be
included in the map.

> map.  The text seems to require that if you have an RDF graph in a
> combination that uses a datatype outside of DTB, then there has to be a
> rule specifically about it.  The text says, "the set of considered
> datatypes is the union of the set of RIF-required datatypes and the sets
> of datatypes used in R...".  Of course "used in" is not formally
> defined, I'm taking it to mean referenced directly in a rule, which

Right.

> seems like an odd requirement - you can only combine graphs with rules
> if you have a rule about every datatype in the graph outside DTB.

This is not implied by the definition. It might be the case that there
are data types in the RDF graphs that are not RIF-required and do not
occur in any of the RIF rules. As per the D-entailment semantics, these
datatypes may or may not be included in a given datatype map. In the
latter case, all literals in this datatype are interpreted as abstract
objects.

> However, I supposed "used in" could be interpreted as meaning
> "understood by any rule engine processing rules in R" and then q.v.
> conformance.

I don't know what "q.v." means, but a datatype being referenced in a
rule indeed implies (by the BLD semantics) that all implementations that
process the rule must understand it, or reject the ruleset.

D-entailment does not have such requirements.

> 
> Really, just as with a ruleset that uses datatypes outside DTB, you just
> want to be sure the implementation knows about the datatypes in the
> graph. Can we just dispense with the "considered datatypes" bit
> altogether and take the conformance route used in BLD?  Was this in
> there because of ill-typed literals?

The present route was chosen to remain faithful to the D-entailment
semantics, which allows you to use arbitrary data types that nobody
needs to understand.
I did not think it was my place to redesign D-entailment, and I did not
want to impose restrictions that would limit the set of RDF graphs that
can be combined with RIF rules.

This has nothing to do with ill-typed literals.

> 
> ...reading on, in 3.2.1.2 Common RIF-RDF Interpretations we have:
> 
> "LV is a superset of (union of the value spaces of all considered
> datatypes); "
> 
> So I guess the problem is how to define LV.  Again, can we handle this
> in the BLD style wrt some sort of conformance?

This particular condition is a restriction, not a definition.
D-entailment requires LV to be a superset of the union of the value
spaces of all data types in the datatype map. I do not see a reason to
restrict this further.
Actually, for that reason, the condition is redundant, but I think it is
useful to include it in the definition for clarity.

> 
> ---
> 
> 3.2.1.2 Common RIF-RDF Interpretations
> 
> "2. IP is a superset of the set of all k in Dind such that there exist
> some a, b in Dind and Itruth(Iframe(a)(k,b))=t; "
> 
> Why is IP is a *superset* of all frame "slots"? You say "Condition 2
> ensures that the set of RDF properties at least includes all elements
> that are used as properties in frames in the RIF domain." however it
> does not require that all rdf properties are interpreted as "slots"?

In RIF, it is not possible to interpret objects as "slots". It is only
possible to use object in slots.
In RDF, there is a specific subset of the set of objects and these are
the only ones that may be used in the property position: IEXT is a
mapping from IP (the set of properties) to the power set of IRxIR.
So, in order to make sure that IEXT is well-defined (i.e., condition 4
makes sense), we need to make sure that all objects used in property
positions are included in IP.

> 
> 2 also seems odd because it mixes interpretations and truth valuation. 

This is because the RIF model theory is defined in such a complex way.
One would rather expect that Iframe(a) would be a set of tuples, and we
could check membership of (k,b) in Iframe(a). However, it is not, so we
have to deal with such complicated constructions...

> What if I have a k such that for all a,b Itruth(Iframe(a)(k,b))=f?  Then
> it isn't defined to be in IP. 

It is not *required* to be in IP, but it may be in IP. For example, it
must be in IP if there is any graph that uses a constant denoting k in a
property position.

> In fact, the explanation of condition 2
> may not be quite accurate, e.g, a deBruijnian sentence:
> 
> Forall ?x ?y ( 1=2 :- ?x[ex:never -> ?y] )
> 
> ex:never is "used as a property" in a frame, even though it can't be
> true for anything.

I do not understand the relationship between your example and the
definition. The definition is about interpretations, not about formulas.

> 
> Maybe this is why IP is a superset (?), but still there is nothing that
> tells me that ex:never is a property in this case.
> 
> Why not something like:
> 
> RIF-I(o[a1->v1 ... ak->vk]) = RDF-I(o a1 v1. o a2 v2. ... 0 ak vk.)
> 
> I have a vague memory of having discussed this before...apologies if I'm
> dredging up something we figured out already.

I believe condition 4 captures what you want to say.

Best, Jos

> 
> -Chris
> 

-- 
Jos de Bruijn            debruijn@inf.unibz.it
+390471016224         http://www.debruijn.net/
----------------------------------------------
No one who cannot rejoice in the discovery of
his own mistakes deserves to be called a
scholar.
  - Donald Foster