Re: Ill-typed vs. inconsistent?

On Nov 14, 2012, at 2:19 AM, Pierre-Antoine Champin wrote:

> Pat,
> 
> On Wed, Nov 14, 2012 at 8:16 AM, Pat Hayes <phayes@ihmc.us> wrote:
> What I still don't follow is, why anyone who understands what an inconsistency is, would even form the idea that an ill-typed literal would be an inconsistency. It's not the distinction that needs explaining, it's why anyone would treat them as similar in the first place.  Illformedness is not even in the same category as an inconsistency. Literals aren't true or false by themselves. 
> 
> I think the divergence of opinion comes from the fact that
> 
> * you see typed literals merely as terms (which, strictly speaking, they are), and a term can not be False; it just denotes something ;
> 
> * others (at least myself!) see a little more in them, namely: an implicit assertion that the denoted thing is indeed in the value space of the datatype.
> 

Yes, fair enough, I think that is essentially correct. 

> If we decide to bite that bullet, then this could be endorsed in the semantic condition for a *graph*:
> 
>   if E is a ground RDF graph then I(E) = false if I(E') = false for some triple E' in E,
>   or if I(E') is not in LV for some typed literal E' in V,
>   otherwise I(E) =true.

Well, yes, but it is kind of strange to have a blanket condition on a graph without going via the triple. (Suppose someone were to say, but the graph is just the conjunction of the triples, so if the graph is false one of the triples must be...) 

Here's another way to achieve the same result:

1. Allow IL to be a partial mapping, ie to fail to have a value for some literals. 
2. Point out (no actual change required) that if IL fails to have a value for a literal in a triple in a graph, then that triple, and hence the entire graph, will be false. 
3. Impose the datatype condition that IL is undefined on ill-formed datatyped literals. (This replaces the current condition that IL(lll) not be in LV when lll is ill-formed: it amounts to saying that IL(lll) is not even in IR.) 

That handles it neatly with a minimal change, and no change at all to the current truth-conditions on graphs. 

If we could put literals in subject position, this would make a host of new D-entailment axioms, i.e. every triple of the form 

"sss"^^ddd rdf:type ddd .

when sss is in the lexical space of ddd. But as we can't, this doesn't really matter. 

BTW, now we have had this long email debate, this way of doing it seems so obvious that I don't know why we didn't do this in 2004. I think probably because I have an aversion to partial mappings in semantics because I dislike free logics, so I simply didn't think it through. Also, nobody in 2004 objected to the current scheme with quite Richard's degree of persistence :-)

> The first line (from the original definition) accounts for everything asserted explicitly in a triple,
> while the second line (which I added) accounts for those "implicit" assertions carried by typed literals.
> 
> Do you think it's a clean way to do it? Or do you consider it as just another "trick" ? :-)

OK, let me walk back a little on the "trick" remark. I think that saying that an ill-typed literal doesn't denote anything is natural, and saying that any atomic sentence (ie any triple) containing a non-denoting name is false, is reasonable. The second part makes me slightly nervous because it has some odd consequences in a full FO logic, but it seems to work OK for RDF. So maybe its not just a "trick" after all.

Pat

> 
>   pa

------------------------------------------------------------
IHMC                                     (850)434 8903 or (650)494 3973   
40 South Alcaniz St.           (850)202 4416   office
Pensacola                            (850)202 4440   fax
FL 32502                              (850)291 0667   mobile
phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes

Received on Thursday, 15 November 2012 22:20:52 UTC