Re: nonmon mapping and punning

On Mar 6, 2008, at 4:35 AM, Bijan Parsia wrote:

> On 6 Mar 2008, at 09:11, Alan Ruttenberg wrote:
>
>> On Mar 6, 2008, at 3:38 AM, Bijan Parsia wrote:
>>
>>> On Mar 6, 2008, at 8:13 AM, Alan Ruttenberg wrote:
>>>
>>>> I thought the issue wasn't in adding or removing one triple, but  
>>>> rather the general truth maintenance issue. Namely you have  
>>>> rules that depend on certain triples existence as antecedents.  
>>>> You don't necessarily known when these rules fire, relative to  
>>>> when you need to retract a statement. If adding something causes  
>>>> you to retract a statement, then you want to also retract all  
>>>> triples that were added based on rules which had the retracted  
>>>> triple as antecedent.
>>>>
>>>> The mechanism you refer to below is possibly adequate to retract  
>>>> a triple (possibly because it isn't clear to me from the spec  
>>>> whether triples added by a reasoner would trigger the event).  
>>>> But it isn't adequate to retract the triples that were added as  
>>>> a result of rules that fired based on it.
>>>
>>> [snip]
>>>
>>> I'm missing something...why would non-monness in the mapping  
>>> force truth maintenance to be necessary? Or be any worse than any  
>>> edit cycle? (E.g., I add something, I delete something...I have  
>>> to update the classification and other cached entailments no  
>>> matter what.
> [snip]
>> It's easier if you add something - you don't have to empty the  
>> cache and start over. (I have to admit, it seems a bit surreal to  
>> be saying this to you, since you know this, of course).
>
> Indeed. So I phrased my question wrong. I don't see why nonmonness  
> in *the syntax mapping* *changes* anything wrt Jena, that is,  
> introduces a *new* factor that makes the design harder.
>
> I guess if you are doing rule based construction of ontologies it  
> might be a bit trickier...but then you don't get big changes of  
> rule based dependancies to resolve. That is, the *particualr*  
> nonmon we're talking about really is just reacting to the addition  
> (or deletion) of a single triple. It's not as nice, clearly, as  
> just adding stuff, but it's clearly not radically at odds with the  
> framework.
>
>> Sure you *could* implement a system that after every insertion you  
>> force a complete reclassification.
>
> But what does this have to do with the non-mon in the *mapping*? If  
> Jena is going to deal with deletions *period* it has to deal with  
> truth maintenance. Either this isn't such a big deal or they  
> already do something.

Jena wouldn't care about the mapping. It would care about dealing  
with what the mapping produces. One imports two ontologies(both in  
rdf/xml), one which doesn't have punning, and the other which does  
have punning, and the game is on.

> Suppose you are running a joseki server and want to support the new  
> SPARQL updates over an RDFS store (or an OWL store using Pellet).  
> Even with a monotonic mapping this requires some way to handle  
> retractions and potentially chained retractions. If Jena makes this  
> impossible as a matter of principle, then, well, I'm speechless. I  
> fail to see that nonmon in the mapping is any *worse* that these  
> scenarios, which seem squarely in the design of Jena, and, in fact,  
> the nonmon in the mapping is a good deal easier.

True.
Do you know that JENA implements deletions on RDFS stores  
efficiently? I would be surprised. Whether this is squarely in the  
design of JENA is uncertain. Even if it is, it doesn't mean that it's  
been done, or is scheduled to be done.
The experience I have with SPARQL Update is with virtuoso, which has  
no reasoning.

>> It's just undesirable, and the mechanisms that let one avoid doing  
>> that are much easier to implement if the system is monotonic.
>
>
> I think you are being mislead by the term "nonmonotonic" here.  
> We're not talking about general nonmononicity of the formalism that  
> would require *inside the reasoning process* something complex. OWL  
> 1.1 is monontonic. There are situations where given two functional  
> syntax ontologies O and O' where O is a proper subset of O' the  
> canonical corresponding RDF for O is not a proper subset of O'.  
> This difference is very specific (i.e., it's not generic).

Sure. But it is not monotonic nonetheless. Maybe you get lucky and  
this specific difference doesn't hurt. But if I was an implementor  
I'd be worried as soon as any nonmonotonicity popped up.

> Jeremy expressed that this was very strongly in conflict with  
> Jena's design and that design was based on semantic web  
> architecture and that it had something to do with being able to  
> retract triples when adding triples.

Consistent with the reasoning story here, and a desired principle of  
monotonicity. Not almost monotonicity.

> I went and studied Jena and found that it had specific support for  
> exactly this scenario that would work well for the situation we're  
> talking about (parsing, serializing, and editing "from a triple  
> perspective").
>
> Obviously, the situation is confusing because Michael raised the  
> OWL interface and you raised reasoning, neither of which were  
> mentioned by Jeremy as far as I can tell.

I inferred from the start that it must be reasoning that is the  
issue, since as you point out the alternative is trivial.

> So I'm still *mystified* as to what the fundamental complaint is. I  
> would like to understand this regardless of how we resolve the  
> related issues (I've proposed a monotonic mapping solution). If  
> Jeremy (or his HP colleague) just had a brain fart, that's one  
> thing. If it's a way our specs could negatively affect  
> implementations, I'd like to know about it.

If the spec implies nonmonotonicity (general or specific, in any of  
the supported syntaxes) then that's worth complaining about. My  
assumption is that it will negatively affect some implementations,  
and we should avoid it, unless there are compelling enough reasons  
that they balance the negative. I don't see that there are, given  
that you've already proposed an alternative.

I'm not against having Jeremy/Colleague coming out and saying this,  
but I think I understand it well enough not to need them to do so.

Regards,
Alan

>

Received on Thursday, 6 March 2008 09:58:28 UTC