Re: please review RIF-in-RDF

On Fri, 2010-06-11 at 00:48 -0400, 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

Progressing well but there are some parts that I think need to be
clearer and some decisions I don't understand.

(1) The translations don't include any rdf:type statements corresponding
the Class nodes in the striped RIF syntax. 

In previous discussions  RIF_in_RDF was, where possible, the same as you
would get by treating RIF/XML as RDF/XML which would include all those
type statements. Without them then any extensions have to invent new
predicate names as discussed in section 4, for no apparent reason. I
found the discussion in section 4 baffling until I realized the type
information is being omitted altogether.

I would prefer dropping section 4 and including the rdf:type
statements. 

(2) The notion of focus_node isn't very clearly explained.

It is not until getting to 5.4 that the reader is told that the
focus_node is a generated bNode except when an <id> was present on the
parent element. I suggest putting a section upfront before table 1
explaining the handling of <id> and then how a focus_node is passed down
to the rhs column of the tables.

In particular the explanation in para 2 of 5.4 ("Metadata about
consts ...") is difficult to follow and I think you need a more formal
description of how focus_node is bound in each case.

[I agree with Axel's comment that making Tr a two arg function would
make explaining the data flow on focus_nodes easier. I didn't quite
follow why Tr has to be on the outer instead of the inner element if
done that way.]

(3) Table two has two special rules which reference mode_1 and mode_2
properties that aren't explained anywhere.

(4) Section 5.5 needs to be expanded or dropped.

I still don't understand the requirement for mapping optional elements
to zero elt lists etc. Off-list we discussed as being a form of built-in
integrity checking. I'm prepared to go along with that, even though I
still don't understand the motivation for it. However, that section
should explicitly enumerate the cases where it applies (in non-extended
syntax).

It would also be a good idea to rename that section "additional remarks"
sounds more like commentary rather than something that substantially
complicates and changes the whole translation process :)

In terms of a FPWD then (3) needs fixing and ideally something to help
with (2). Issue (1) could be handled as an editor's note for now and (4)
can wait for a future draft.

Dave

Received on Tuesday, 15 June 2010 10:39:15 UTC