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

From: Bob MacGregor <macgregor@ISI.EDU>
Date: Fri, 10 Jan 2003 19:22:13 -0800
Message-Id: <5.1.1.6.0.20030110191842.00b52c90@tnt.isi.edu>
To: pat hayes <phayes@ai.uwf.edu>
Cc: seth@robustai.net, Dave Reynolds <der@hplb.hpl.hp.com>, www-rdf-interest@w3.org
```
Some conclusions are in order.

I certainly have a better understanding of some of the issues
in RDF regarding reification and nested statements.  Below,
I've listed a number of conclusions that summarize my interpretation
of the current state of affairs.  Within that list are a couple
of technical questions for which I still lack answers.
I get the feeling that only a portion of the WG has understood
the full import of some of the decisions that have been made.

However, the net result is disappointing.  It seems like the
WG Charter may be impeding progress on RDF (and the Semantic
Web), but that's just a guess.

(1) There are some fairly simple things that one would like
to say in RDF that are not expressible.  Here are some examples:

Suppose we start with a triple that states
"Fred Martin is 52 (years old)".  Assume that 'S1' is that triple,
in the abstract sense, not in the sense of a stating.

Here are some things I would like to be able to say about S1:

"The probability of S1 is P"
"S1 is true at time T1"
"I disagree with S1"
"The object value of S1 is wrong.  The correct value is 53
(i.e., retract S1 and assert 'Fred Martin is 53')"
"S1 is important (take note of it)"

(2) Some of the WG members appear to be unaware of this defect.

Here is a quote by Seth Russell to that effect (I imagine he is
not alone): "But I really don't know any practical case where we
would want to say something about a jena:Triple" (here I'm
assuming that 'jena:Triple' means 'statement').

(3a) One means for alleviating the problem in (1) with regard
to examples I've listed would be to permit statements to
be nested.  Nested statements are explicitly forbidden
(apparently by the WG charter).

(3b) A second means for alleviating the problem in (1) would
be to admit reified statements (using the traditional sense
of that phrase) into RDF.  Although that appears to have
been sanctioned in the original RDF, it has now been forbidden.

(4a) KIF provides an existence proof of a logic language
that explicitly allows nested statements and does not
introduce paradoxes.  Question: Is the Charter the only
reason for forbidding nested statements, or are there
technical reasons as well?

(4b) Allowing unfettered use of reified statements would
make it very easy to introduce paradoxes.  Taking (4a)
into account, if reified statements were constrained
by the same semantics as nested statements, then I'm guessing
that the possibility for self-reference, and therefore
paradox, might be eliminated.  Has this been explored?

(5) Some of the WG members appear not to be aware that
ordinary reification is not merely unsupported, but is
actively discouraged.

Brian McBride: "there are two concepts - statements and statings and only one
bit of vocabulary.  The WG, for reasons that Pat Hayes has explained picked
one for the existing vocabulary, and as Pat also mentioned,  that
does not preclude you, or anyone else, from defining new vocabulary
for the missing concept."

My guess is that Pat explicitly does not want me or anyone else
to define vocabulary for the missing concept, i.e., for statements,
because "its too dangerous" (which I translate as "it might

(6) Its very easy to write statements about statements and
never introduce paradoxes (freeways are dangerous, but its
easy to walk beside them without crossing them).  Users have
the option to pretend that statings are in fact statements,
and then use the RDF statings machinery to make assertions
about them.  In my case, we appear to have no choice; our
application requires the ability make assertions like those
listed in the beginning, and no alternatives have yet been
offered up.  I'm not worried about the so-called 'danger',
but its disappointing that no legitimate alternative
has been suggested.

(7) The RDF Semantics Document
http://www.w3.org/TR/2002/WD-rdf-mt-20021112/
contains a section on Reification that is quite difficult
to read.  This is not a criticism per se, because the
subject itself is relatively difficult.  However, it is
not reasonable to think that many readers could make a
pass through it and know what they had just read.

On my first pass through, I noted that the term 'token' is
used repeatedly but never defined.  That made things tougher.
The term 'stating' never occurs.  It took several readings to
determine that what was said did in fact seem to jibe with
the notion of stating that has appeared in the discussion groups.
That also made things more difficult.

(8) Parts of the OWL document
http://www.w3.org/TR/2002/WD-owl-semantics-20021108/
are even more abstruse (c.f., the very short section
on OWL-FULL).  I can't tell from scanning it
whether any of my examples can be expressed in OWL.  If
OWL indeed is the solution to some of our problems, I
would like to see some examples.

(9) The triple stores that have emerged in conjuction with
RDF could in principle solve all of my current problems.
However, the restriction that they conform to RDF semantics
means that they can't handle the examples I've listed.  Since
Jena currently allows one to include statements as arguments
to other statements and RDF does not, for my purposes one
of Pat's claims is exactly backwards:

Pat Hayes: But the fact is that triple stores are a limited tool,
and RDF is committed to the use of this very restricted tool.

Jena 1.6 already gives me what I need except for some tiny
tweeks to the API.  My guess is that Jena's current representation
(ignoring unbridled reification, which I don't use) can be
embedded as a subset of KIF, thereby making it logically
sound.  However, owing to its commitment to RDF,
Jena 2.0 is scheduled eliminate the statements-as-arguments feature
(replacing it with statings as arguments?).  This is, to say
the least, disappointing.

Cheers, Bob
```
Received on Friday, 10 January 2003 22:30:08 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:07:44 UTC