>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/~phayess.pam@ai.uwf.edu for spam