Re: Ill-typed vs. inconsistent?

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.

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

> 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. But defining it the other way would have been entirely reasonable.

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 related to the formal model theory, and applications may treat ill-typed literals the same way they treat inconsistencies (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. 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

Received on Tuesday, 13 November 2012 12:07:10 UTC