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

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

Received on Wednesday, 21 July 2010 11:41:02 UTC