Re: [jena-dev] Re: Use cases for Reification in RDF Triplestores

At 04:25 PM 1/9/2003 -0800, pat hayes wrote:
>>(3) If you want to explicity refer to a statement in RDF (which many KR 
>>systems
>>do on a routine basis
>Evidence for this? I do not know of any.

There seems to be an amazing disconnect here, and I'm not sure where the
divergence first occurs.  I've been assuming that the terms "statement" and
"logical sentence" are synonymous.  If that's a mistake, please let me know.

So, let me stick with 'sentence', in the KIF sense.  Let S1 be a sentence.
I might want to assert that "S1 is true", "S1 is false", "S1 is true in context
C1".  In these cases, I'm each case I'm explicitly referring to the
sentence/statement S1.

Or, I might want to assert that "The likelihood of S1 being true has 
probability P".  Again,
I'm explicitly referring to a sentence.

Or, I might want to assert that "S1 is true at time T1".  Once again, a rather
ordinary reference to a sentence.

Now, all of these examples can be handled by the nesting of 
sentences/statements
within other sentences/statements.  To me, a statement S2 that contains
S1 as an argument is explicitly referring to S1.

Hence, we have another possible source of disconnect.  Pat claims not to know
of any cases where one would want to refer to a statement.  To me, all of the
above cases are evidence of this.  Again, maybe some other terminology should
be used, so if someone can suggest the appropriate restatement of
the above examples, I'd be glad to see it.

Some languages, including RDF, forbid
nested statements.  In that case, if we still want to make any of the above
statements, we need some other mechanism.  Some systems use quotation
for this.  However, when you quote a statement, the resulting object loses
a portion of its semantics, so quoting seems to be less prevalent than it once
was.

Another possible out is reification.  To 'reify' in the dictionary sense 
means 'to
make concrete', which is a somewhat abstract notion that is open to more
than one interpretation.  In the past, many of us have used 'reify' to mean
'to convert a tuple into an instance'.  The intent of this operation was to 
permit
the appearance of a (representative of a) tuple in locations where the 
tuple was
syntactically illegal.
However, there was no intent to subvert the semantics of the tuple, say from
being a statement into being an event/occurence of the assertion of a
statement (i.e., a stating).  Instead, reification was considered as a 
functional
operation, yielding exactly one result per application.

So, the question is, how should I represent any of the above examples
in RDF?  I can't use nesting (except in Jena, which apparently will be
phasing it out).  I can't use quotation; I can't use reification as I have
just described it.  There is no notion of 'event' or 'occurrence' in any
of my above examples, except for the temporal one, so the use of a
stating would be odd indeed.  But lets investigate it:

Now, its true that if I observe the existence of a triple in an RDF triple
store, there must have been some agent that caused that triple to have
appeared there.  That means that there must have been a stating
(perhaps even more than one) that caused that triple to appear.  And each
those statings implicitly refer to my triple.  So if I were to locate
a resource representing one of the statings, then I could pretend that
the stating event was not an event at all, but was a stand-in for the
statement, and just reference it.  Or, I could invent a whole new class
of predicates, so instead of saying "S1 is false", I could say find a
stating for S3, and say "the statement referred to by S3 is false".  Or
I could say "the statement referred to by S3 is true with probability P",
or "the statement referred to by S3 is true at time T".

I could do that, but it would be wrong (to quote Richard M.).  And it would
be relatively inefficient.

>>(6) Jena and other RDF-compliant triple stores will likely not give us direct
>>support for reasoning about statements in the future.
>
>If you are willing to use a bit of OWL expressivity (see above) you will 
>probably be OK.

OWL is a language.  Expressing things in OWL buys me nothing unless there
is a software tool that efficiently implements whatever that construct is.
At present, therefore, you are not offering me anything that I could use.

>>  That means that we will
>>have to work harder to get the preferred semantics from a triple store, and
>>will have to work harder to achieve good performance.
>I am honestly mystified as to what kind of performance you have in mind 
>here that will be so hard to get.

I believe you.  We would be happy to send you the source code for Loom or 
PowerLoom if you
want to see what an efficient (and very clever) context mechanism looks 
like (the
cleverness is primarily due to Austin Tate's group in Edinburgh).

But the fact is, if the "shortcut" reification that now exists in Jena
were modified only slightly, we could get significant performance improvements
for reasoning with the kinds of examples listed above.  That shortcut lies 
outside
of the bounds of RDF, since it involves nested statements, but with the correct
interpretation of reification, the shortcut could be justified as being 
isomorphic to
a much clumsier and slower Reified Statement construct.  Now, that opportunity
for efficiency seems to have gone out the window.

We may be able to invent
caching techniques to compensate for the loss in performace -- I'm not sure 
yet.

>>thus widening the gap between what RDF provides and what a KR system needs.
>
>There are two separate issues here: reification on the one hand, and 
>allowing nested expression structure on the other.  RDF does not allow 
>nested structures, and it is beyond the WG's charter to extend it to do 
>so, but that has got nothing to do with reification.
>It is indeed a pity that RDF is so propositionally weak and inexpressive, 
>if one wants to think of it as a full KR language. Clearly it is not a 
>full KR language.  To extend it to allow full propositional expressivity 
>would have gone beyond the WG's charter. I would suggest that you think of 
>RDF as a useful way of encoding simple atomic assertions and use some 
>extension of RDF to encode more elaborate propositional content. The new 
>OWL-full standard shows that this is indeed possible, with some care, and 
>a bunch of us are working on an extension which will provide full FOL 
>expressivity, and you can choose your own subset.

The really neat thing about RDF is the emergence of the notion of a triple 
store
(e.g., Jena).  RDF itself is just an unpleasant-looking serialization 
syntax, which
we don't actually use very often.  OWL is just another syntax.  Perhaps you are
saying that a ground-up implementation for an FOL version OWL would give me 
the kind of
performance I'm looking for.  That may well be true, but (1) that 
implementation
will likely be a long time in coming, and (2) it probably won't be able to 
exploit today's
triple stores, since by following RDF dictates they are probably insuring 
that their performance
for full FOL will be suboptimal.

>Many people have suggested using reification to simulate expression 
>nesting in recursive syntax, but  this kind of usage for reification was a 
>mistake from the start. A complex expression like
>(A and B ) or (C and D)
>does not *mention* its disjunctive components,

I disagree.

>so to use reification to encode complex propositional expressions in a 
>triple store was a semantic disaster waiting to happen. (This point has 
>been labored to death in many email forums.)  If the WG decision on 
>reification has rescued you from doing that, be thankful.

Certainly I'm not thankful, since I don't know what I might have been 
rescued from.
I could imagine that there are esoteric problems (e.g., paradox) that could 
have been
easily legislated away without eliminating this form of reification.

You seem to have thrown the baby out with the bathwater.

Bizarre thought:  It occurs to me that maybe you don't want me to be able 
to express any of
my above examples in RDF.  I'm supposed to wait for OWL superheavy, or 
something.
Is that the problem?

Cheers, Bob



Phone: 310/448-8423, Fax: 310/822-6592
Mobile: 310/251-8488

Received on Thursday, 9 January 2003 22:23:29 UTC