Re: nonmon mapping and punning

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.

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.

> No one is saying that's not possible with Jena.

Actually, I'm close to hearing that from Jena.

> 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). 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. 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. 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.

Cheers,
Bijan.

Received on Thursday, 6 March 2008 09:33:11 UTC