- From: pat hayes <phayes@ai.uwf.edu>
- Date: Thu, 9 Jan 2003 16:25:45 -0800
- To: Bob MacGregor <macgregor@ISI.EDU>
- Cc: seth@robustai.net, Dave Reynolds <der@hplb.hpl.hp.com>, www-rdf-comments@w3.org, www-rdf-interest@w3.org
>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