Re: Inference for error checking [was Re: How to avoid that collections "break" relationships]

On 03/31/2014 01:39 PM, David Booth wrote:
> On 03/31/2014 11:59 AM, Peter F. Patel-Schneider wrote:
>> [...]
>>
>> Given this error checking objective, if a system is given the facts:
>>
>>   x ppp y .
>>   y a ccc .
>>
>> then without also knowing that "ppp schema:domainIncludes ccc", the
>> system may not be able to determine that these statements should be
>> considered Passed or Failed: the result may be Indeterminate. But if
>> the system is also told that
>>
>>   ppp schema:domainIncludes ccc .
>>
>> then it can safely categorize these statements as Passed (within the
>> limits of this error checking).
>>
>> Sure, but it can be very tricky to determine just what facts to consider
>> when making this determination, particularly with the upside-down nature
>> of schema:domainIncludes
>
> My assumption in this example is that the application already has a set of 
> assertions that it intends to work with, and it wishes to error check them.

It is quite tricky to figure out what this set of assertions should be?  For 
example, are consequences of other facts allowed?  All of them?
>
>>>
>>> Thus, although schema:domainIncludes does not enable any new
>>> entailments under the open world assumption (OWA), it *does* enable
>>> some useful error checking inference under the closed world assumption
>>> (CWA), by enabling a shift from Indeterminate to Passed or Failed.
>> The CWA actually works against you here.  Given the following triples,
>>
>> x ppp y .                       # Triple A
>> y rdf:type ddd .                # Triple B
>> ppp schema:domainIncludes ccc.  # Triple C
>>
>> you are determining whether
>>
>> y rdf:type ccc.                 # Triple E
>>
>> is entailed, whether its negation is entailed, or neither.  The relevant
>> CWA would push these last two together, making it impossible to have a
>> three-way determination, which you want.
>
> I don't think that's quite it.  The error check that I described is not the 
> same as checking whether NOT(y rdf:type ccc) is entailed.  (Such a 
> conclusion could be entailed if there were an owl:disjointWith assertion, 
> for example.)  It is checking whether (y rdf:type KnownDomain(ppp)).  In 
> other words, the CWA is not being made in testing whether (y rdf:type ccc); 
> rather it is being made in computing KnownDomain(ppp).

Huh?  What is this KnownDomain construct?  Where does it come from? How is it 
computed?
>
> The net effect of this is that the CWA is being used to distinguish between 
> cases that would all be considered "unknown" under the OWA.

I still don't see a play for the CWA here.
>
> David

peter

Received on Wednesday, 2 April 2014 16:05:31 UTC