Re: Toward closing the RIF-in-RDF open issues

[response at end]

On Wed, 2010-07-21 at 12:40 +0100, Dave Reynolds wrote:
> Hi Sandro,
> 
> [Responses inline]
> 
> On Tue, 2010-07-20 at 20:18 -0400, Sandro Hawke wrote: 
> > Dave, you expressed the opinion that RIF in RDF [1] should use the
> > existing terms, eg rif:formula instead of rif-in-rdf's rif:allTrue.
> > This is ISSUE-102 (and brings in ISSUE-101, later).   Obviously,
> > everyone is welcome to join in, but I don't think anyone else has
> > commented on these issues yet.
> > 
> > While in general I agree with the principle of not changing things
> > unnecessarily, I think these changes were sufficient motivated.  I'm
> > hoping to quickly convince you of that; you've said you wont formally
> > object to this, but I'll be happier if I can actually convince you,
> > since then I'll have more confidence in the design.  (And in the distant
> > future, looking back, we can share the credit/blame.)
> 
> :)
> 
> > There are several different situations where I've made up new property
> > names.  In decreasing order of confidence:
> > 
> > (1) for Var and Const, as in
> > http://www.w3.org/2005/rules/wiki/RIF_In_RDF#table1
> > 
> > I'm not sure you had any issue with these; I don't see any way to use
> > the existing RIF XML vocabulary here, so I had to make up something.
> 
> Agreed, that's fine.
> 
> > (2) For "mode 3" transforms, the elements under the <slot> element.  The
> > <slot> element is used both for argument names and for frame slots, and
> > in both cases it's used to hold two items whose role names are not
> > given.   Since normal RDF modeling uses role names, I had to make up
> > something.   I thought it best to separate the argument and frame uses,
> > so I offered argname/argvalue and slotkey/slotvalue.    I could see an
> > argument for using key/value for both, but I also already used rif:value
> > for Consts.
> 
> Agreed. There's no RIF naming to reuse there, at least for frames. I
> might have gone for a uniform rif:slotname/rif:slotvalue for both but am
> OK with your solution.
> 
> > (3) For "mode 2" transforms, where a property element is optional or
> > repeatable, I've had to change them each into a required occurs-once
> > property whose value is a list.   For example, in XML rif:directive can
> > be used zero or one time; to meet Requirement 4 (which we can talk
> > about in a separate thread), I had to put that into a list.  Since it's
> > differently structured, it seemed like another name was appropriate.  I
> > like the practice of using plurals for list-valued properties, so I
> > proposed rif:directives.    Given that I had to rename these properties
> > (directive, sentence, declare, formula), the choice of how to rename
> > them was informed as below.
> 
> As I commented before I have problems with requirement 4 or at least the
> "being reduced to a subgraph bit" of it. As you say, we could cover that
> on a separate thread. 
> 
> So I don't see the need to translate each of those cases to lists and it
> has the disadvantage of slightly complicating queries.
> 
> So *if* the change in representation is needed then the change in name
> makes sense, I just haven't bought the antecedent ... yet.
> 
> > So far, so good, I hope.
> > 
> > (4) Finally, since I was already renaming, I tried look at how usable
> > the rules might be in their RDF graph form.   The key point here was
> > ISSUE-101, whether to use rdf:type.   For example, does
> > 
> >    <And>
> >      <formula>$a</formula>
> >      <formula>$b</formula>
> >    </And>
> > 
> > turn into:
> > 
> >         [ rdf:type rif:And; rif:formulas ( $a $b ) ]
> > 
> > or just:
> > 
> >         [ rif:some-new-predicate ( $a $b ) ]
> >         
> > I believe this is a pretty arbitrary decision.  OWL RL can be used to
> > transform either way between these two forms.   My sense is that it
> > will be somewhat simpler for programmers to just have to think about
> > the predicates, and never have to generate or look for class arcs.   If
> > they want to generate or consume the And/formulas form, they can do
> > that, using an RL reasoner to do the conversion.
> 
> So here we disagree a little.
> 
> Yes it is somewhat arbitrary and either could work.
> 
> My mild preference for including the type arcs is based on:
> 
>   - OWL specifies the type arcs, defining which are optional, so at some
> level it's established practice in W3C specs
>   - as a programmer if I'm walking a tree I'd expect to be able to test
> the type of a node directly rather than have to infer it from the
> properties hanging off the node
>   - it allows us to keep more consistent naming and structure with the
> XML syntax, keeping RIF-in-RDF closer to being RIF-XML treated as
> RDF/XML
>   - it allows the possibility of using repeated properties, instead of
> lists, for things like And/Or (and so ties back to the requirement 4
> discussion)
> 
> Taken together this is not a totally compelling "you must do it this
> way" kind of case but it is at least slightly stronger than
> "arbitrary". 
> 
> Let me turn this round. Is the above enough to convince you the we might
> as well have the type nodes?
> 
> > Interestingly, I note that the OWL RL rules don't check for the
> > (similarly redundant) rdf:type owl:Restriction, but the OWL 2 RDF
> > Mapping rules do.  Hmmm.
> 
> Yes, OWL is clear in what required even though OWL RL rules don't check
> that. 
> 
> > I thought about rif:andFormulas as the name of the predicate, but
> > decided rif:allTrue was probably more clear.     I approached the other
> > renamings with the same mindset: what name would be easiest for someone
> > working with the RDF graph form to get right.  I suppose an alternative
> > approach would be to minimize the distance from RIF XML terminology,
> > with andFormulas, forallDeclares, etc, but those struck me as pretty
> > awkward.
> 
> Sure. If you are going to have node-dependent predicate names pointing
> to lists instead of following the RIF-XML structure then names like
> rdf:AllTrue are indeed preferable.
> 
> > (5) Finally, if I was doing as in (4) above, renaming to avoid type arcs
> > since I needed to rename anyway, there was exactly one property left
> > that still required a type arc.  So, I decided to rename it, too, so no
> > type arcs would be needed anywhere.  This is rif:op; in an Atom, I
> > proposed it be renamed to rif:predicate, and in an Expr that it be a
> > rif:function.  In some ways, these seem like more conventional names.
> > (I think at least one earlier design of the syntax of BLD used these
> > names.  I vaguely remember us all talking Harold out of it at an F2F at
> > Mitre.)
> 
> Sure, if we resolve Issue-101 as not requiring type arcs are choose the
> names you have in (4) and might as well finish the job and do (5) as
> well.
> 
> > The name changes are from (3)-(5) are in table 3:
> > http://www.w3.org/2005/rules/wiki/RIF_In_RDF#table3
> > 
> > and an example of how it comes out is in section 10, the "Complete
> > Example" appendix.
> > 
> > It would be nice to write the ontology, use that to deduce the classes,
> > and then serialize it as RDF/XML with the class information.  I guess I
> > need to do that for the next (and final) round anyway.  
> > 
> > ( One thing that's not clear to me there: should the ontology introduce
> > BLD's all-caps "classes", saying things like "rif:Expr rdfs:subClassOf
> > rif:UNITERM."?  It makes logical sense, but it makes the above
> > serialization harder/uglier; you don't want to use rif:UNITERM in the
> > serialization (and you don't really want to decide that based on its
> > capitalization, or maybe even it's place in the class hierarchy, since
> > there might be subclasses of Expr some day. ) )
> 
> I would specify the serialization to just include those type nodes that
> are used in the XML serialization. I would not define the serialization
> without type notes and then add them back in again via the ontology.
> After all the ontology will also entail lots of other trivial facts
> which you don't want to include either.
> 
> I'd be inclined to not include the all-caps classes in the "ontology"
> anyway but I haven't sat down to try to write it out.
> 
> > So, that's the motivation.   Please let me know where you remain
> > unconvinced, how strong that feeling is, and if you have any ideas for
> > things I can do to put these decisions on more solid ground.  :-)
> 
> I remain unconvinced but don't feel very strongly about the naming
> issues per se. I feel a little more strongly (but not die-in-a-ditch
> strongly) about Issue-101 and requirement 4, the consequences on naming
> are in some ways secondary.
> 
> Cheers,
> Dave

Okay, it sounds like I should dig more into Requirement 4, and show why
I think using list values is necessary.  (And maybe [hopefully] I'll be
proven wrong; using lists like this is, indeed, kind of a pain.)   I'll
try to do this soon.   That may even shed a little more light on the
type-arc question.

    -- Sandro

Received on Wednesday, 21 July 2010 12:40:53 UTC