Toward closing the RIF-in-RDF open issues

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

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.

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

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

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


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.

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.

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

(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

The name changes are from (3)-(5) are in table 3:

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

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

    -- Sandro


Received on Wednesday, 21 July 2010 00:18:44 UTC