Re: please review RIF-in-RDF

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.

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?


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

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

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 Sunday, 13 June 2010 10:50:23 UTC