W3C home > Mailing lists > Public > public-rif-wg@w3.org > June 2010

Re: please review RIF-in-RDF

From: Sandro Hawke <sandro@w3.org>
Date: Thu, 17 Jun 2010 01:25:32 -0400
To: Dave Reynolds <dave.e.reynolds@googlemail.com>
Cc: public-rif-wg <public-rif-wg@w3.org>
Message-ID: <1276752332.14684.14.camel@waldron>
On Tue, 2010-06-15 at 11:38 +0100, Dave Reynolds wrote:
> 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. 

As you suggest below, I've made an editorial note for now.  I don't see
any strong reasons to include rdf:type arcs in the mapping, and it seems
simpler to omit them, but if we end up with people wanting them added,
that's fine to do later.

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

Yeah, I'm really sorry for the rush-job quality here, and thanks for
bearing with me.   (It's been one high-priority thing after another for
weeks, and now I'm trying to do this, on vacation, when the kids are
asleep.   Back at my desk tomorrow.)

To at least clarify this all for myself, I did a straight-forward
implementation today.   It seems to work for BLD Example 8; I'll try to
run it over all the test cases, and do the extractor (for proper
testing) tomorrow.


... if you like.   Once I'm happy the code works, I'll try again to turn
it into spec-English (tomorrow or friday, when I'm back at work).

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

Yeah, I have a mental model for use-case-4 that requires this, but
obviously I haven't communicated it properly.

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

indeed ..., sorry.

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

Great; I just might make it.

   -- Sandro
Received on Thursday, 17 June 2010 05:25:44 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:47:58 UTC