Re: please review RIF-in-RDF

On Sun, 2010-06-13 at 11:33 +0100, Axel Polleres wrote:
> Sandro, all,
> 
> Sorry I didn't have a chance to look at it earlier, but here a review for RIF-inRDF...
> I also won't be able to join the extra calls, since I am traveling until 23rd.
> 
> First of all, I think it is a good start, thanks for the effort.

And thanks for the review!

> Overall comments:
> 
> * 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?

Yes, I think that makes sense.  I'll give it a try.  

> * Intuitively, I would expect that atomic ground RIF frame formula are translated 
>   to RDF facts, but I can understand why that is difficult (e.g. adding meta-data). 
>   So, if it is not possible, than - at least - I would rather suggest to reuse the rdf 
>   reificiation vocab, than creating a new one, i.e.
>     rif:object --> rdf:subject
>     rif:slots[rif slotkey .. --> rdf:predicate
>     rif:slots[rif slotvalue .. --> rdf:object

The semantics just are not the same, so I don't see how to do that.
rdf:subject links to the thing itself which is the subject of the
triple.  rif:object links to a syntactic element which might be constant
which links to the thing itself, but could also be a variable.  If you
used rdf:subject, how could you handle variable subjects?
 
> * 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.

Hmmm.  I wonder how to spell this out properly.   Maybe I just need to
write the demo code to clarify what I'm talking about, ... but I don't
have time to do that on our current schedule.   And this is a working
draft.  Could there just be an editor's note just talking about the
issue?

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

Yeah, I didn't set out to change any names; the earlier designs used
exactly the same names, until I ran into the problem of needing to make
it be a list instead of a repeated property.   So when we have a single
property, what do we call it?   I think having rif:and and rif:And be
quiet different things is really not okay.   So, given, that, I didn't
know what else to do.

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

They're just handled by the default mapping rules in table two.   Some
of them might need entries in table three.

> * 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) 

Sure, some kind of reference, or non-normative appendix seems fine.

The rest all look fine.

   -- Sandro

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

[ You just can't reference something much less mature; so this couldn't
got to Rec before Turtle did.  I don't think that'll be a problem. ]

> * @@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.
> 
> 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 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 01:13:49 UTC