Re: Ill-typed vs. inconsistent?

On Nov 13, 2012, at 4:06 AM, Richard Cyganiak wrote:

> Pat,
> 
> Some quick replies here before going over to the other thread where you make a proposal for resolving this...
> 
> On 12 Nov 2012, at 17:21, Pat Hayes wrote:
>> But for example, suppose you wanted to use xsd:number but your data has the occassional entry of  "zero" to mean "0". Right now, you could just let this slide past and the parsers would not actually break. And you could even assert that the value was a number without anything breaking. 
> 
> Well, not quite. You can't actually assert that it's a number.
> 
>  "zero"^^xsd:decimal a xsd:decimal.
> 
> Now it's inconsistent.
> 
> Also, if I wanted to explicitly “clean up” those weird zero literals by asserting:
> 
>  "zero"^^xsd:decimal owl:sameAs "0"^^xsd:decimal.
> 
> Again, this is inconsistent.

> 
> You say that "zero"^^xsd:decimal not being itself an inconsistency is a feature because it allows the expression of useful facts about the ill-typed literals while staying consistent. I'm not convinced that it actually does allow that.

True. OK, I will retract that claim :-)

> 
> 
>> Inconsistency isn't an error.
> 
> Well, shall we put it this way? Whether an inconsistency should be treated as an error depends on the application, and therefore the core specs shouldn't imply that it is an error; they should describe it as a logical condition on RDF graphs, as you say below.
> 
>> If you want to suggest that we make ill-typed literals into a version of a syntactic error, I would go along with that, but it has consequences for parsers that the 2004 WG thought were too onerous.
> 
> I agree that ill-typed literals should not be syntactic errors, for the reasons you mention.

I actually think they should be. Illformedness is, after all, a purely syntactic matter. And if we make them into inconsistencies, engines will still need to do the same work in checking wellformedness, so the pragmatic arguments seem to apply in either case. 

> I also don't think that limiting the allowed datatypes to only a fixed set of built-in types is feasible at this point; in 2012, removing custom datatypes would just not fly.

I tend to agree, but then we are left with a host of issues about how to treat "unknown" datatyped literals.

> 
>> This is a well-known can of worms for logicians, which is one reason typed logics were invented, to push ill-typing into the syntax in order to keep the semantics from getting hopelessly muddy.
> 
> So here you seem to be saying that the distinction between “ill-typed” and “inconsistent” is not there because it's useful. It's there for technical reasons related to the particular approach chosen to define the model theory of RDF. In short, the distinction simplifies the definition of Semantics.

No, it does not make Semantics any easier. (Writing a model theory for a typed logic is a nightmare of complexity.) Rather, having syntactic typing keeps the actual inference process cleaner, and catches errors earlier. Much the same arguments are made for strong typing in programming languages. Myself, I prefer untyped languages like LISP, BCPL and RDF. 

> But defining it the other way would have been entirely reasonable.

With hindsight, there is another way to proceed, yes. 

But, let me emphasise, however we decide to handle this, there is a clear *conceptual* distinction between inconsistency and ill-formedness. Consistency has to do with truth: inconsistent means, necessarily false. Being ill-formed or otherwise syntactically peculiar is a different topic altogether. So I didn't, and still don't, see any particular reason why these two notions shold be conflated. Having them separate was not an artificial oddity, it was simply a natural thing to do. On the face of it, they are not even particularly closely related to each other, except perhaps in that they are both ways of being "bad" in some vague sense. The simple trick I suggested for making ill-formedness into inconsistency is exactly that: a trick.

> 
> Thus, a distinction that isn't actually useful in Concepts land gets pushed out of Semantics and into Concepts territory.
> 
> I can live with that. Concepts can say informatively that the distinction is there for technical reasons

It is "there" for the same reason that there is a distinction between chalk and cheese. They are different.

> related to the formal model theory, and applications may treat ill-typed literals the same way they treat inconsistencies

Same way?? In that they both might trigger some kind of error, I guess, but not in any closer way. An inconsistency can arise, for example, from putting together data from two sources which simply disagree about the facts. This isn't a plausible account of how an ill-formed literal can get there.

> (which may range all the way from “be completely oblivious to their presence” to “raise the alarms and launch all missiles”). (And just to be clear, the previous sentence does not imply that ill-typed literals *are* inconsistencies.)
> 
>>>>> Is there any reason anybody needs to know about this distinction who isn't interested in the arcana of the model theory?
>>>> 
>>>> I'm not sure what you consider to be "arcana". Someone who cannot follow the model theory probably shouldn't be using RDF.
>>> 
>>> That's crazy talk.
>> 
>> Do you really think that the idea of inconsistency is mysterious to the average RDF user?
> 
> The average RDF user may well be able to grasp the idea of inconsistency. But the relevant question here is whether the average RDF user is able to work out for themselves why ill-typed literals in RDF are neither a syntactic error nor an inconsistency.

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. 

Pat

> Regardless of whether they are capable of doing that, I don't think they should have to. That's why I raised ISSUE-109.
> 
> Best,
> Richard
> 

------------------------------------------------------------
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 Wednesday, 14 November 2012 07:16:50 UTC