Re: Review of RIF in RDF

Hi Axel, 
> 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 [].

It would be more intuitive but it doesn't do the same job because it is
a syntactic artifact of the RDF/XML and disappears once you get to the
RDF graph.

It's clearly true that <> resolves to the base URI of the document,
which in turn is either the xml:base or the URL at which the document is
supposed to be published.

However, from the point of view of a RIF processor all they see is the
URI, they don't see the "<>" syntax, there is no way to know that that
URI was the base URI of the source document. E.g. consider the case
where the graph was obtained from a triple store or where you are
loading from a file but the file contains an xml:base. 

So *if* the graph is actually published at the base URI then it works.
You dereference the URI and what you get back happens to be the same as
the graph you hold in your hand.

The difference with the [] trick is that the latter works even if the
graph URI isn't dereferencable and indeed avoids you having to do the
dereference at all.

That said, I regard the self-reference as a corner case and am happy to
drop the [] option.

> 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. 

Yes that seems to work.

> 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."

That doesn't quite work. We don't at the moment have any specified way
to combine two RIF rule sets and the RIF-in_RDF encoding ensures that
you end up with two RIF Documents not one Document with a union of the
rules.

For current RIF dialects you could indeed just concatenate all the
groups in the source documents into a single group and since order
doesn't matter then there is no ambiguity. However, there are rule
languages (and thus possible RIF dialects) where syntactic order or
rules affects rule priority so rule set combination is order-dependent.

I suggest tackle this as a MAY:

"Remark 4. Note that in the case where the graph G includes encoded RIF
rules then, as a result of RDF graph merge, it may encode more than one
RIF document. A RIF-in-RDF process MAY choose to combine all the rules
in each documents into a single RIF document or MAY issue a warning.
Note that future RIF dialects may have semantics which depend on rule
ordering."

Dave

Received on Sunday, 26 September 2010 10:24:41 UTC