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

>Well, I'm taking an earlier suggestion by Dave Reynolds and
>posting to rdf-comments as well as rdf-interest (but not to Jena
>since this isn't a Jena issue at this point).
>
>At 10:28 AM 1/9/2003 -0800, Seth Russell wrote:
>>Yes, the WG has decided, nodes of rdf:type rdf:Statement *are* 
>>statings, I think you guys should accept that and move on.
>
>I apologize for my ignorance on WG decisions; I missed this 
>particular one.  I would appreciate someone mailing me a pointer to 
>the published decision.

Im off-web at the moment, but you should be able to find it on the 
RDF home page and I think there are  links to it in the RDF 
documentation.

>What Seth's comment above says is that the RDF provides for a means 
>for referring to
>statings, but does not provide a means for refering to statements.  This is
>an unfortunate blunder

It might be a mistake, but it wasn't a blunder. We made this choice 
carefully and with our eyes open, and after extensive consultation.

>  on the part of the WG, since between the two, its more
>common to want to say things about statements than about statings.

That is not the impression we got from our constituents. In fact, the 
decision to go this way with reification was taken because almost all 
the use cases that we were able to discover, after making energetic 
enquiries and repeated public requests for comment and feedback, 
made sense only with this interpretation of reification, and there 
were almost none that used the statements interpretation. From a 
purely semantic point of view, the 'statements' interpretation is 
easier to describe and more natural. I was all for it for these 
reasons at first, but was obliged to cede the point that however 
elegant it might be, it wasn't of the slightest practical use; 
whereas the 'statings' sense clearly was of considerable use and 
indeed was being actively used by RDF users.

>  However,
>allowing for both would have been much preferable than excluding 
>statements about
>statements.

Not including something in RDF does not prevent anyone introducing it 
as an RDF extension. Our brief was to clarify and systematize 
existing usage of RDF, not to extend the language by adding new 
options.

>
>>Of course if you want to discuss a node that represents a Platonic 
>>triple, then there is nothing preventing you from describing such a 
>>thing as ( _:tHASHofTRIPLE, rdf:type, jena:Triple ).   But I really 
>>don't know any practical case where we would want to say something 
>>about a jena:Triple.   Do you?
>
>While underneath (at the implementation level)
>there are many kinds of reasons for saying something about a 
>Jena:Triple, Seth may
>be right in that we don't want to say anything about it at the RDF 
>level.  However, many
>of us DO want to be able to refer to a "Statement" at the RDF level. 
>In this case, its
>convenient to let the Java statement instance denote the 
>"mathematical" statement
>(that's what the Jena shortcut does), which is the thing we want to 
>be able to reference.
>
>Summarizing:
>
>(1) Statements and statings are not the same thing.

Indeed, but they are closely related. A statement can be viewed as an 
abstraction of a class of syntactically isomorphic statings. One gets 
a statement from a stating by ignoring some of its properties,  so 
all you need to do to get a theory of statements is to use statings 
but explicitly, er, state that you are doing the ignoring. eg you 
might introduce an RDF property 'hasForm' between statements and 
statings, and then use an RDF reification as the object of a triple:

aaa jena:hasForm _:xxx .
_:xxx rdf:type rdf:Statement .
-:xxx rdf: subject ......

and so on, where aaa here is your statement. If you want to get 
technical, you could also say

jena:hasForm rdf:type owl:inverseFunctionalProperty .

or if your powers run to extra inference rules, you could have a 
special semantic extension with the rule

aaa jena:hasForm _:xxx .
_:xxx rdf:type rdf:Statement .
-:xxx rdf: subject sss .
_:xxx rdf:property ppp .
_:xxx rdf:object ooo .
bbb jena:hasForm _:yyy .
_:yyy rdf:type rdf:Statement .
-:yyy rdf: subject sss .
_:yyy rdf:property ppp .
_:yyy rdf:object ooo .

==>

aaa owl:sameIndividualAs bbb .

>(2) If you want to explicitly refer to a stating in RDF, use a 
>reified statement (apologies
>for the bastardization of the phrase 'reified statement' to refer to 
>something else).

The actual term is 'a reification'

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

>), you are out of luck.

No, you have to use one extra triple, see above.

>(4) Seth says "just move on".  The WB has blundered (my opinion but 
>not his) and
>there is nothing we can do but accept it (his opinion but not mine).

At this stage, that is all you can do, yes.

>  Since the Jena
>folks are committed to compliance with RDF, I guess that's what they must do.
>
>(5) Faced with a choice of compliance with RDF or building a robust capability
>for reasoning about statements, I will personally choose the latter.

That seems to me like a damn silly choice, frankly, unless it is 
motivated by some special-purpose applications I do not know about. 
Why on earth do you want to reason *about* statements? Very few 
ontologies are about statements, and in any case statements are not 
really worth having an ontology of: all they are is recursive syntax, 
so why would you use an assertional language to describe them? That 
seems a poor choice on both pragmatic and semantic grounds.

>  This is
>unfortunate, since it means that our tools will not be RDF-compliant.
>
>(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.

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

>
>(7) The more advanced KR systems routinely nest statements within statements
>(e.g., for expression disjunction, rules, beliefs, etc).  Among 
>other things, this
>ability to nest frequently eliminates the need to reify a statement

That seems like a very odd thing to say, rather like saying that the 
ability to sing eliminates the need to stand on one foot. Nesting 
hasn't got anything to do with reification.

>  -- a good thing,
>since reified statements (in the true sense of the phrase, not the RDF sense)
>are inherently clumsy, and should be avoided when possible.

Indeed.

>The WG group's decision appears to have legislated out this 
>possibility for RDF

Which possibility? Nesting or one version of reification? RDF *never* 
had expression nesting, from day one, so you can hardly complain at 
it not having it now all of a sudden, when extending RDF is 
explicitly forbidden by the WG's charter.  We chose one sense of 
reification; it is easy to add the other (but if we had made the 
other choice, the 'statings' sense would have been completely 
inaccessible, and so many existing uses of reification, eg to express 
provenance information, would have been rendered meaningless or 
illegal.)

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

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

Pat
-- 
---------------------------------------------------------------------
IHMC					(850)434 8903 or (650)494 3973   home
40 South Alcaniz St.			(850)202 4416   office
Pensacola              			(850)202 4440   fax
FL 32501           				(850)291 0667    cell
phayes@ai.uwf.edu	          http://www.coginst.uwf.edu/~phayes
s.pam@ai.uwf.edu   for spam

Received on Thursday, 9 January 2003 19:30:37 UTC