W3C home > Mailing lists > Public > www-rdf-rules@w3.org > June 2005

Re: Web Rule Language - WRL vs SWRL

From: Bijan Parsia <bparsia@isr.umd.edu>
Date: Wed, 29 Jun 2005 17:30:02 -0400
Message-Id: <6106713b335f80363431f25bd929ab94@isr.umd.edu>
Cc: www-rdf-rules@w3.org
To: Michael Kifer <kifer@cs.sunysb.edu>

On Jun 29, 2005, at 4:49 PM, Michael Kifer wrote:

> Bijan Parsia wrote:
>>
>>>> [Trimming down to www-rdf-rules]
>>>> On Jun 28, 2005, at 3:09 PM, Michael Kifer wrote:
>>>> [snip]
>>>>
>>>>> This wasn't clear from the paper.
>>>>> In any case, the claimed interoperability doesn't extend to the 
>>>>> more
>>>>> powerful languages.
>>>>
>>>> That this wasn't claimed (or at least strongly suggested) certainly
>>>> isn't clear from the architecture diagram that has rules and OWL
>>>> "overlapping" with DLP. Similarly, the DLP "shield" diagram also
>>>> strongly suggests that the interoperabilty isn't restricted in the 
>>>> way
>>>> you suggest.
>>>
>>> Sorry, you lost me here...
>>> In any case, I see no point in arguing about what was "suggested" or
>>> "clear" from this or that diagram.
>>
>> Perhaps you should just acknowledge that most of the pro-DLP patter 
>> has been
>> very *unclear* about exactly what compatibility it affords.
>
> It has been clear to those who claimed it.

Then they should have been clearer about it.

> You might have had a different set of defaults though.

Whatever.

>> I mean, you claim that the claimed interoperabilty was limited in 
>> certain ways
>> but 1) I've not heard that *limited* claim from the DLPers before 
>> this and 2) I've
>> heard plenty that, I'll, for the sake of charity, say "suggests" a 
>> great deal of
>> interoperabilty.
>
> You may be exaggerating the "plenty" and the "great deal" parts.

You may be minimizing those parts.

I've also had to explain (what I think) the compatibilty/incompatibilty 
really is, both theoretically and in practical terms. This suggests 
that it was somewhat less generally clear.

But whatever.

>> Even if they are, up to "pragmatically negligable" semantic mismatch,
>> semantically compatible, the subsetting approach doesn't actually 
>> allow for
>> reasonably free interaction between the formalisms.
>
> No, nothing is free (except for an occasional lunch).

I mean "free" as in "unconstrained". My lunches are always highly 
constrained.

And by "reasonably unconstrained" I mean "somewhat, and hopefully 
natural, but not too restrictively, constrained".

But who cares :)

>> Which, I would submit, is a reasonable objective.
>
> Some objectives might be reasonable, but unachievable.

Well, since there are many degrees of interaction conceivable, I would 
hold out for the maximal that is achievable and seems sensible.

[snip]
>>> You seem to think that practitioners delve into the semantics of 
>>> things --
>>> big mistake!
>>
>> The practictioners I work with do. I encourage and support them in 
>> that.
>
> This reminds me of the early days of SQL. Back then people believed 
> that
> practitioners will actually understand the semantics *and use it*.

I wonder if Date et al would diagnose things the same way.

(Actually, I don't wonder. I so believe :))

> The reason SQL is  such a screwed-up language is because the authors 
> went
> out of their way to make it "understandable" by non-experts.

I think your thrashing around a bit. I don't expect practitioners to 
read model theories, but I do expect them to have a practical working 
idea of the semantics. And they do. I'd prefer that the semantics be 
clear enough so that people can bootstrap that working idea into a 
deeper and better informed understanding, but I certainly don't expect 
everyone to do so.

So, I'm confused as to your point. Is it that formal semantics, correct 
semantics, or compatible semantics doesn't matter? Really, I'm at a 
loss, especially given your earlier claims that people expect certain 
semantics. Novices generally don't. Experts generally do, based on 
their training. So?

> (Back then people thought that a company manager will actually be able 
> to
> type correct queries and get answers from a DBMS.)

I think the HCI issues in all of this are severe and important. I've 
not even begun to try to tackle the task of reaching substantively 
end-user accessbility...it's unclear that they will do any modeling, or 
rather, that they will do any formalism based modeling (i.e., where 
they express their modeling intent as a set of formulas). I do think 
Web developers can be brought to that level, but they need a lot of 
support. (Hence, my work on better ontology editors, debugging, etc.)

[snip]
>> And on the Web, we will expect a kind of interoperability between 
>> solutions to
>> these problems and a *chance* of reusing your solution to a 
>> particular problem
>> in a context that you did not imagine.
>>
>> Or rather, I think that's what we're aiming at, pie-in-the-sky as it 
>> may be.
>
> It depends how high is your sky. If you are aiming at the 7 heavens, 
> then
> it is perhaps too high.

Do you agree that this is what we're aiming at, at least some variant, 
suitably low? I can't see you are aiming at that at all, from what 
you've said. In fact, you've been quite vague about the standard of 
interoperabilty

>> So, why don't we talk about possible integration frameworks?
>
> Yes, why?

I'm not sure. I've put some text out.

I do think that autoepistemic approaches like the K operator are 
promising. We are implementing it in our reasoner. This would be a 
variant of subsetting (i.e., SWRL + K operator would allow expression 
of standard datalog like kbs, I believe).

(Roughly, this is the DL-Log approach that Franconi et al discuss.)

>> After all, if we can put a plausible solution on the ground I think 
>> we can move
>> forward. And, if we are to follow what you've said thrice, it should 
>> be a
>> framework that supports arbitrary KR integration.
>
> I don't believe that arbitrary is possible. But reuse of solutions is 
> possible.

I mean, arbitrary KRs. Not arbitrary integration. So, what kind of 
reuse?

Cheers,
Bijan Parsia.
Received on Wednesday, 29 June 2005 21:30:10 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:53:12 GMT