Re: please review RIF-in-RDF

A few more thoughts....

On Sun, 2010-06-13 at 11:33 +0100, Axel Polleres wrote:

> * The translation in Table 2, would be easier to write down, if you use a bit 
>   more formal notation... I suggest to use a two-paramater translation function   
>   tr(Expr,focus_node)
>   and another function fresh_blank() that creates new blank nodes... then you can write 
>   table 1 as follows:
> 
>   tr(<Var>variable-name</Var> ,<i>focus_node</i>)   | <i>focus_node</i> rif:varname "variable-name"
> 
>   ... similarly for the following lines, but you don't need the "Special rule" just write:
> 
>   tr(<elem><i>ElemContent</i></id>...</elem> focus_node)  | 
>       tr(<i>ElemContent</i> blank() )
> 
>   tr(<id><i>Const<i></id> focus_node)  |       tr(<i>ElemContent</i> id )
> 
>   the other lines work again similar to the first...
> 
>   Do I make sense here?

I wasn't able to make this work.  One of the problems, formally, is that
right-hand-column tr() call needs to be about elem-without-id, not
elemContent.  For the second row, that's a non-progressing recursion.
The solution is to have tr1 and tr2, but that gets pretty complicated.
I think it'll be simpler for readers to simply handle <id> entirely
out of band.  I've moved it out of the table into a section with <meta>

> * note: round tripping including RDF(S) inference is a noble goal but in general simply 
>   not feasible, particularly in RIF-RDF(S)-combinations. 
> 
>   Imagine a RIF ruleset R and a graph G consisting of the single triple:
> 
>   rif:allTrue rdfs:subProperty rif:anyTrue
> 
>  This almost certainly causes troubles, and I see no way to avoid these troubles.
>  So, I would weaken the claim/requirement for round-tripping even with inference.
> 
>   (besides I think hat the names should be closer to rif, i.e. rif:anyTrue --> rif:or 
>    rif:allTrue -->rif:and, etc. , I don't see huge benefits in inventing yet another set  
>    of new names/URIs, where the correspondence with the RIF element names isn't clear 
>    upfront.)

I think the real problem is just about subgraphs/incompleteness.   I
rewrote Req4 in the hope of making that clearer.

> * What about rif:imports and the other directives? How where is it modeled in the RDF? Am I missing something here? At this stage, I can't yet figure how that'll look in RIF/RDF
> 
> * As for the reverse mapping and ideas for it: I think that expressing the reverse 
>   mapping via (SPARQL-like?) patterns is a good idea...
>   This immediately makes me think that a reverse translator should be doable in XSPARQL 
>   [1]. Would that be desired? Could be reference it in the spec? (Given that we also 
>   reference the Turtle submission, it seems yes) 
> 
> Some smaller comments details:
> 
> Section 1:
> 
> * Turtle [@@ref]
> [@@ref charter]
> sw/wiki/Tools[@@ref]  ... (How) can we reference non-rec docs? We probably just need to distinguish normative vs. informative References.
> 
> * @@extractor ... ? why is the @@ ?
> 
> * "The rest of this document is:"
>   -->
> "The rest of this document is structured as follows:"
> 
> * RIF to RDF transform
>  --> I kinda prefer
>  RIF to RDF transformation
> 
> Section 2:
> * "easier for some communities of users"
>  --> too vague, just say
>  "desirable in some cases"
> 
> Section 5: 
> 
> * before Section 5.1 you explain the tables, but not what they are for, I suggest to add some one sentence what each table provides in temrs of content, not only how it is to be read.

I still need to do this.  That'll require more brainpower than I have
left this morning, so ... later.

> Section 5.2
> 
> "@@ Random Bits [@@ how to present this editorially]"
> 
> For the moment, I would just rename that section "Additional Remarks" and move it after the tables.
> 
> I don't understand what the last paragraph is about "Note that even ..."
> 
> Section 5.2.1
> 
> Not yet sure where this is going yet... ;-)
> 
> "Reverse tranforms should accept as input an RDF graph and the IRI of the rif:Document to extract. They may accept as input an RDF graph and extract all the rif:Documents present in the graph."
> --> rather 
> "Reverse tranforms should accept as input an RDF graph and the IRI of the rif:Document to extract. They may accept as input an RDF graph and extract all the rif:Documents represented by the graph."
> 
> 
> That's all for now,
> Axel

On the naming, I added an editors note that the names are not settled.

How's it look?   Think it's good enough for FPWD once I take care of the
@@-bits?

   -- Sandro

> On 11 Jun 2010, at 05:48, Sandro Hawke wrote:
> 
> > 
> > While it's still not done, the RIF-in-RDF spec is coming along, and I
> > think is ready for people to read.   The incomplete parts are marked
> > with '@@@' and a comment about what's still needed.
> > 
> > http://www.w3.org/2005/rules/wiki/RIF_In_RDF
> > 
> > (Thanks to Dave for a few rounds of comments so far.)
> > 
> >     -- Sandro
> > 
> > 
> > 
> > 
> 
>

Received on Monday, 14 June 2010 14:48:40 UTC