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

I haven't given this issue a deep thought, but I find Dave's argument to
be compelling (that it would have been nice if the design of RIF-in-RDF made it
look like RIF-XML treated as RDF/XML).

This gives unity to this whole suite of specs.

michael


On Wed, 21 Jul 2010 08:40:43 -0400
Sandro Hawke <sandro@w3.org> wrote:

> [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 Thursday, 22 July 2010 05:33:45 UTC