Re: Review of RIF in RDF

Dave,

sitting in the train... finally I manage (just still in time, I hope) to read your proposal in detail. 
My frank apologies for answering late.

Question 1:
==========
First of all, I like the self-import idea... that's particularly what I hadn't thought of when 
defining my version.

You suggest in version 1:

 [] rif:usedWithProfile P .

but as you say yourself that maybe not totally intuitive... what about just: 
 
 <> rif:usedWithProfile P .

instead? it seems you don't need an absolute URI to self-reference, do you? Isn't <> just "self"... at lease 
I'd find it more intuitive to define <> as "self" rather than [].

I can live with 

 [] rif:usedWithProfile P .

but I *personally* find the other suggestion more intutitive (and actually they seem to work even in your version 2 already, but one might 
want to add a explaining text. I would suggest just to take your version 1 and replace [] with <> in Remark 3. 

Question/Remark 2:
==================
My main use case is that I want to be able to use RIF rulesets with FROM/FROM NAMED clauses in SPARQL:
Intuitively, from SPARQL's point of view ... it would have been desirable for me if I could have used 

FROM <R1>
FROM <G>

where R1 is a ruleset to use R1 with graph G. In that, even if R had the self-import triple, 
I would get also all the triples of the R1 encoding as "data" which I don't want (but which 
covers the behavior that Sandro wanted, actually!)

I understand the problems with that from your earlier mail... A work-around to achieve 
the same with your proposal seems to be:

let <g1> be an auxiliary graph with one triple
 <R1> rif:usedWithProfile :Simple .

Then

 FROM <g1>
 FROM <G>
 FROM NAMED <R1> 

seems to solve what I want... I think I have to assume for SPARQL that <R1> is at least in the named graphs to have it "accessible" for processing, but having it only in the named graphs of the dataset seems to work to keep the encoding triples out of interference with the data of G. 


Question 3:
===========

What if G contains more than one rulesets, e.g. if G was obtained by the merge of 
two RDF encoded RIF rulesets? Does the extraction work with several rulesets merged into one graph as well?
That would be very desirable, for my use case (querying RDF with various rule fragments of RDFS/OWL encoded in RIF... 
I just could encode each rule in a separate ruleset, and merge the onese I need.)
I think in this case, we'd need to reword your version of Section 8 as follows:

change:

"Let R be either the empty RIF rule set or, if G contains a
rif:usedWithProfile triple with a blank subject node, then let R be the
rule set obtained by inverting the Tr mapping to extract any rules
encoded within G."

to:

"Let R be either the empty RIF rule set or, if G contains a
rif:usedWithProfile triple with a blank subject node, then let R be the
rule set obtained by inverting the Tr mapping to extract any rules
from any ruleset encoded within G. Note that (by RDF graph merge) a single 
RDF graph could encode more than one RIF ruleset."

Long story told short, what you suggest seems to work for me and also for sandro (and probably is the only thing we can reach now) so, 
let's go for it, modulo clarification of Questions1+3.

Axel

 
 


> [2] Suggested text for sections 7/8
> 
> [[[
> 7. Importing RIF into RDF
> 
> SWC [RIF RDF+OWL] defines the entailments of combinations (R, G) where R
> (a RIF rule set) includes an import of G (an RDF graph).
> 
> We hereby define an RDF predicate <code>rif:usedWithProfile</code> which
> enables an import to be specified from the graph G instead of from R.
> 
> In the simple usage the graph G is a plain RDF graph and
> <code>rif:usedWithProfile</code> is used to combine that graph with one
> or more externally defined RIF rule sets. In this usage each subject of
> a <code>rif:usedWithProfile</code> assertion should be the URI for a RIF
> rule set (which may be encoded in RIF-XML or RIF-in-RDF) and the object
> should be an import profile as defined in SWC [RIF RDF+OWL].
> 
> It is also possible for the graph G to itself contain both an encoded
> ruleset along with additional RDF statements to which the ruleset is
> intended to apply. This usage is supported by using a blank node as the
> subject of a <code>rif:usedWithProfile</code> assertion.
> 
> 8. Semantics of RIF in RDF
> 
> A RIF-in-RDF-aware processor shall treat any RDF graph G as a RIF-RDF or
> RIF-OWL combination [RIF RDF+OWL] as follows:
> 
> Let G' be the graph obtained from G by removing all triples with
> predicate rif:usedWithProfile.
> 
> Let R be either the empty RIF rule set or, if G contains a
> rif:usedWithProfile triple with a blank subject node, then let R be the
> rule set obtained by inverting the Tr mapping to extract any rules
> encoded within G.
> 
> Then G is to be treated by a RIF-in-RDF-aware processor as the ruleset
> R' by amending R  with the following  imports directives:
> 
>     Imports(R1)
>     ...
>     Imports(Rn)
>     Imports(G' P1)
>     ...
>     Imports(G' Pn)
> 
> Where Ri and Pi are the subjects/objects respectively of triples of
> form:
>     Ri rif:usedWithProfile Pi     where Ri is a URI reference
> 
> Remark 1: Note that the fact that G' is treated as being imported with
> all profiles P1 ... Pn enforces G' to be treated according to the
> highest profiles among P1 ... Pn, cf. Section 5.2 of [RIF RDF+OWL].
> 
> Remark 2: Note that if G includes an encoded RIF rule set then the
> triples that make up that encoding are visible in the (R', G')
> combination.
> 
> Remark 3: If the graph G can be obtained from URI Ug then including the
> triple  
>      [] rif:usedWithProfile P .
> is equivalent to including:
>     <Ug> rif:usedWithProfile P .
> I.e. self including the graph as a rule set has the same effect as
> explicitly including the same graph as an external ruleset.
> 
> Remark 4: Note the discussion in the section 6 that the inversion of Tr
> is not a deterministic function.
> ]]]
> 
> Editor's Note: The support for self-inclusion by using a blank node may
> be controversial. If so then drop that in order to get to publication.
> In that case the suggested text is:
> 
> [[[
> 7. Importing RIF into RDF
> 
> SWC [RIF RDF+OWL] defines the entailments of combinations (R, G) where R
> (a RIF rule set) includes an import of G (an RDF graph).
> 
> We hereby define an RDF predicate <code>rif:usedWithProfile</code> which
> enables an import to be specified from the graph G instead of from R.
> 
> Each subject of a <code>rif:usedWithProfile</code> assertion should be
> the URI for an externally defined RIF rule set (which may be encoded in
> RIF-XML or RIF-in-RDF) and the object should be an import profile as
> defined in SWC [RIF RDF+OWL].
> 
> 8. Semantics of RIF in RDF
> 
> A RIF-in-RDF-aware processor shall treat any RDF graph G as a RIF-RDF or
> RIF-OWL combination [RIF RDF+OWL] as follows:
> 
> Let G' be the graph obtained from G by removing all triples with
> predicate rif:usedWithProfile.
> 
> Then G is to be treated by a RIF-in-RDF-aware processor as the ruleset
> R:
>    Document (
>     Imports(R1)
>     ...
>     Imports(Rn)
>     Imports(G' P1)
>     ...
>     Imports(G' Pn)
>    )
> 
> Where Ri and Pi are the subjects/objects respectively of triples of
> form:
>     Ri rif:usedWithProfile Pi
> 
> Remark 1: Note that the fact that G' is treated as being imported with
> all profiles P1 ... Pn enforces G' to be treated according to the
> highest profiles among P1 ... Pn, cf. Section 5.2 of [RIF RDF+OWL].
> 
> Remark 2: Note that if G itself includes a RIF ruleset encoded as
> RIF-in-RDF then no special additional processing is performed, those
> encoded rules are not included in R. If the Graph G is available from
> some URI Ug then it is possible for G to reference itself as a rule set
> by including the triple:
>     <Ug> rif:usedWithProfile P .
> 
> Remark 3: Note the discussion in the section 6 that the inversion of Tr
> is not a deterministic function.
> ]]]
> 
> 
> 
> 
>