- From: Sandro Hawke <sandro@w3.org>
- Date: Thu, 30 Dec 2004 11:06:37 -0500
- To: Pat Hayes <phayes@ihmc.us>
- Cc: www-rdf-logic@w3.org, "Peter F. Patel-Schneider" <pfps@research.bell-labs.com>
Ouch. Harsh e-mail, which I think is the result of a misunderstanding. I'll get to it in more detail in its context, but the short version is that I never meant to indicate that I or "the W3C" was strongly attached to a rule language being a same-syntax extension to RDF. It's something that could be very useful, however, and it's worth coming up with a clear message on how feasible it is. On with the message. Thank you for the reference and details on the Montague result, and its connection to KIF's formalisms. In working out my next response in this chain with Peter I was torn about whether to take the high road and try for a real truth predicate which somehow worked in RDF or the low road and pick something that merely works, without being very powerful and tricky at all. The Montague result confirms my suspicion that the high road, while appealing from a distance, is impassible. The low road, which involves essentially removing the second Montague condition, still appears available. But let's talk motivation and process first. > If you want simplicity, surely a 'natural' syntax for FOL (or OWL, > for that matter) is simpler than any kind of RDF embedding? Simpler for some applications, certainly. RDF was hatched as a metadata format, however, and I'm concerned that some key metadata applications wont work this way. The semantic challenges of reference loops come naturally with the web, whether or not we use RDF. (This point is discussed more in [5] and [6].) > >I keep hearing about projects using RDF > >encodings of Horn or FOL, and they turn out to have either unclear or > >inconsistent semantics. If we're going to move to a standard here, it > >would help to clear up whether it is possible to do this kind of > >encoding properly. > > WHY? Why not get the standard done first, and then argue later about > how to do an RDF encoding? The two problems are closely related, and if both are to be addressed in the next few years by the W3C, it should probably be by the same WG. > Or, even more radically, why bother with > an RDF encoding? That's the key motivational question here, yes. I observe that some people seem to want an RDF encoding. My goal in this thread is to come up with a consensus message for them, such as "Don't do that, because [list of convincing reasons]" or "Here's a way to do it, which has certain [listed] difficulties, but works for [listed application]." > Why do you have this RDF syntax bee in your bonnet? Dont get me > wrong. Im all for RDF, and I like using it for all kinds of things > that it can be naturally used for. But it does have its limitations. Maybe people disagree about what's natural. When working in LISP, Prolog, or most scripting languages, it's quite natural to go between program code and program data, to eval data, treating it as code. In C or Java, or most compiled languages, it's quite unnatural. The first Montague condition is perhaps like offering eval; the second is something much more ... weird. Cool, but not necessary. Something like more like eval'ing an undefined string. > >I can't imagine, for instance, that the approach > >taken by SWRL 0.6 would ever be approved in a W3C Recommendation, for > >the reasons I outlined in the team comment [1]. > > The semantic web can make its own standards without the W3C > imprimateur, if the W3C insists on being insane. But I think you are > wrong, in fact, since the W3C's own WGs are going to be producing > draft recs which don't satisfy these requirements. Ooops! Sorry! I was not clear here. I should not have made my meaning depend on you following the link. Arg. I meant "the approach TO LAYERING ON RDF taken by SWRL" is not likely to ever be approved by the Consortium. The linked text says: SWRL connects with RDF in two ways. The crucial connections is that RDF graphs can be directly expressed in SWRL (using only the obvious syntactic transformation) and they have exactly the same meaning. This allows SWRL rules to operate on and produce RDF data. It also allows a SWRL syntax to be used as an RDF syntax. A second connection is presented in section 6 of the submission, an RDF syntax for SWRL. The goal here is to allow RDF systems which know nothing of SWRL to store and process it as if it were any other RDF data. Ideally, when authoring RDF content, someone could add a quick rule in SWRL, just as they can add little bits of OWL. This second connection is technically challenging to specify fully and correctly. The submission warns that for the encoding in section 6 to be used, non-standard RDF semantics must be used. WE SUGGEST THAT REQUIRING NON-STANDARD SEMANTICS FOR A LANGUAGE IS LIKELY TO CAUSE A GREAT DEAL OF CONFUSION AND SOME MARKET FRAGMENTATION. We greatly hope the path forward for SWRL includes an RDF encoding with full and correct RDF semantics, and an eye towards real user applications. It was the here-capitalized part I was talking about. I highly doubt the W3C would Recommend a rule language which was layered on RDF but only worked if you used non-standard RDF semantics. I'm pretty sure you'd object to such a Recommendation, as would I, unless there was some amazingly good motivation. It appears you thought I was saying W3C would never recommend something which did NOT have an RDF syntax. That helps explain the vehement tone of your message. Sorry again for the confusion! It's hard for anyone to speak "for W3C"; the only real way to do it is to put a statement out for the appropriate level of consensus gathering and see whether consensus is achieved. In this case, you may recall the rule language working group charter draft I circulated last year [4]. It said a layered-on-RDF syntax was one option the WG should consider. Since that charter was not put before the members (let alone approved), it's not official, but I will note that no one said that developing such a syntax should be manditory. > You can get past the barrier by weakening the notion of reflection, > which breaks the second Montague condition. This is how the KIF > metatheory wriggled past the paradoxes, by putting a syntactic tweak > into the truth predicate so that it doesnt apply to some expressions. > But this is a tricky operation to get right. It works in KIF partly > because KIF does reification very transparently, using direct > quotation, so the syntax of the coded expression can be accessed > straightforwardly when stating the necessary constraint. This would > break if, for example, the language used an encoding mechanism that > allowed identity statements between encoded names (this is Peter's > observation). So if you were to do this for RDF somehow, the trick > might fail when you moved to OWL (because of owl:sameAs). I'm not sure I see how, but I'm not sure if you're talking about the KIF3 "true" predicate (from Don Perlis) or the KIF98 "wtr" simpler non-looping predicate. It sounds more like KIF98. I don't think Perlis' approach has the same problem. But this is very close to taking the high road, which I'm okay not even thinking about unless some good motivation appears. I just came across a rather nice :-) message in which I talked this through in more detail [5], and a nice followup from Daniel Mahler [6]. The thread died there, though, I guess. > >Meanwhile, it is "obvious" how to write them informally and with > >subtle errors. > > It SEEMS obvious, but appearances are misleading. It seemed obvious > to Frege, until Russell pointed out the problem. Right. That's why I put the word "obvious" in quotes. The fact that it seems obvious is a problem, because it means people will keep trying to do it, and may even formally object to a WG trying not to do it, unless we can clearly explain why it's a bad idea. Quoting Montague at them is probably part of that explanation, but only part. > Why do you want to be able to push all SWeb languages through an RDF > pipeline? While I've disavowed this being a requirement, yes, I do still think this would be useful. I'll answer in that spirit. Basically for the same reason I want to push all the other data in the world through an RDF pipeline. The good things about putting data in RDF -- using ontologies to express common ground, using URIs for extensibility, data fusion for free, uniform chunks to point at in metadata, being able to write simple and complete fast data stores (triplestore), having a simple query language -- would all be kind of nice to have for applying to rules, too. In the database programming world, people often find it useful to put bits of database code into the database. This is like having "eval" -- it's a nice trick, and people will generally use it if it's available, but it can also get messy, and is frowned upon in some circles. Many of the above advantages also apply to XML, of course. As I say, this isn't a requirement, but I suspect it would be a nice feature. And it's something people will surely do anyway, unless there's a clearly stated reason against it. It SEEMS to me that my "uncle" use case can be addressed, without a problem, by simply removing the second Montegue condition. But I'm going to post this in the hopes of clearing up the misunderstanding now, and work through the low-road details separately. -- sandro > >[1] http://www.w3.org/Submission/2004/03/Comment (in the "RDF" section) > >[2] http://www.w3.org/TR/rdf-mt/ > >[3] http://lists.w3.org/Archives/Public/www-rdf-logic/2004Dec/0022.html [4] http://lists.w3.org/Archives/Public/www-rdf-rules/2003Nov/0028.html See section 2.3 (list item 1) [5] http://lists.w3.org/Archives/Public/www-rdf-logic/2002Sep/0013.html [6] http://lists.w3.org/Archives/Public/www-rdf-logic/2002Sep/0015.html
Received on Thursday, 30 December 2004 16:03:56 UTC