Re: Expressiveness of RDF as Rule Conclusion Language (was Re: W hat is an RDF Query? )

>    [Gerd Wagner]
>    I believe that most people working in the area of logic 
>    programming (and deductive database) semantics consider 
>    logic programming rules as inference rules and not as
>    implications. 
> 
>    The intended (i.e. stable) models of a rule [P if not Q]
>    are not the same as the intended models of the corresponding
>    material implication [not Q -> P] = [P v Q].
> 
> This seems like a crucial issue to settle, given the charter of this
> group.  I know some people are expecting an RDF-rules system to extend
> the logic of RDF in a substantive way.  Such people would want rules
> to be interpreted as implications, because then RDF+rules would be
> more expressive than RDF alone.
> 
> I guess my question is procedural.  Are we allowed or encouraged to
> extend RDF in this way?

Can we work in both directions at the same time?   I imagine both
inference rules and implications being useful, perhaps in somewhat
different application spaces.

I don't exactly understand the difference, myself.  I appreciated
Gerd's comment above, because it validated by own confusion over which
way to understand a logic program.  I think n3 logic [1] [2] shows the
same confusion.  The syntax and terminology ("log:implies") suggest
implication, but its usage in forward chaining by the implementation
(cwm) sounds like inference rules.  (cwm actually will infer new rules
and use them.  What does that sound like?)

Can someone give me a test case which shows where the difference is?

> If not, then it seems like there isn't much to discuss.  As has
> already been suggested, a rule would be of the form P -> Q, where P
> and Q are both RDF graphs with some nodes variabilized.  They could be
> used either forward or backward. 

I'm trying to figure out a good way to "variabilize" the nodes.  I
suggested earlier that we could simply use the bNodes (aka anonymous
nodes, aka document-scoped existential variables), with some special
rules for connecting their scopes.  It has been pointed out to me that
linking their scopes is quite counter to RDF design; for instance,
RDF/XML has no way to name these variables.  (Jonathan Borden
suggested [3] one could use XPointer, but that seems very awkward
here.)

So let's consider using normal node & arc labels as variables. Something like

   FOR ALL x
   IF <x> <http://purl.org/dc/elements/1.1/title> "World Wide Web Consortium"
   THEN <x> <http://purl.org/dc/elements/1.1/name> "World Wide Web Consortium"
   
Or maybe:

   FOR ALL [A-Z].*
   IF <X> <http://purl.org/dc/elements/1.1/title> "World Wide Web Consortium"
   THEN <X> <http://purl.org/dc/elements/1.1/name> "World Wide Web Consortium"

I don't think we can simple pick a pattern (as above) as standard,
because if it's in the URI-Reference syntax, we'll be unable to name
some nodes, and if it's not, then some RDF software wont handle the
RDF graphs we're using as rule premises and conclusions.  But maybe
a patten like .*#?.* would be okay.

I think with this kind of approach, the interpretation of bNodes as
file-scope existential variables works perfectly.  In the premise,
they are just anonymous universal variables (because they are inside
the "if"), and in the conclusion they become skolem functions of the
universal variables, which is very useful.  

I'm not asking idly.  I'm trying to pick an approach to implement
asap.  I'm leaning toward the regexp approach.

    -- sandro


[1] http://www.w3.org/DesignIssues/Notation3.html
[2] http://www.w3.org/2000/10/swap/log
[3] http://www.openhealth.org/RDF/rdf_Syntax_and_Names.htm

Received on Thursday, 4 October 2001 17:23:48 UTC