Re: RDF-ISSUE-109 (ill-typed-so-what): What's the consequence of a literal being ill-typed? [RDF Concepts]

On 11 Nov 2012, at 17:45, Pierre-Antoine Champin wrote:
> I read your proposal as :
> 
>   any graph containing ill-formed literals should be inconsistent under rdf-entailment
> 

> but recognizing an ill-formed literal in the general case requires a knowledge of all possible datatypes.
> So this makes it impossible to decide with certainty if a graph is rdf-consistent in the general case.

I wasn't making a proposal. I was asking for clarification regarding the difference between ill-typed and inconsistent.

> It differs from the current situation because, as you point out,
> any RDF processor supporting a given entailment regime can decide with certainty if a graph is consistent or not under that regime -- although of course it can not say anything about its consistency in other regimes, which is ok.
> 
> So all processors will agree that the following graph:
> 
>     :foo :prop "abc"^^xsd:integer .
> 
> is consistent under rdf-entailment, and insconsistent under xsd-entailment;
> and that the following graph:
> 
>     :foo a owl:Nothing.
> 
> is consistent under rdf-entailment, xsd-entailment or rdfs:entailement, but inconsistent under owl-entailment.
> 
> Again, my problem is not that different entailment regimes differ,
> it is to make one entailment regime undecidable in practice,
> especially the most basic one (rdf-entailment).
> 
> I hope I made my point clearer.

This sounds quite confused to me.

You cannot have an ill-typed literal without a datatype map. The very definition of “ill-typed” relies on the presence of a datatype map. And when you have a datatype map, then there's nothing undecidable about the question whether a given literal is ill-typed.

But that's all besides the point. My question was why the specs distinguish between the two things in the first place. Even in XSD entailment, this is consistent:

  :a :b "xxx"^^xsd:integer.

But this is not:

  :a :b "xxx"^^xsd:integer.
  :b rdfs:range rdfs:Literal.

I don't understand the point of singling out the concept of the “ill-typed literal”, declaring it to be a “non-syntactic error”, but not declaring it to be an inconsistency.

Best,
Richard



> 
>   pa
> 
> PS: regarding the mandatory inclusion of xsd datatypes, it was just an idea, but I won't fight for it :) It sounded to me as a more acceptable compromise toward your proposal.
> 
> 
> On Sun, Nov 11, 2012 at 1:29 PM, Richard Cyganiak <richard@cyganiak.de> wrote:
> Hi Pierre-Antoine,
> 
> Thanks for the response.
> 
> On 11 Nov 2012, at 10:59, Pierre-Antoine Champin wrote:
> > I'm affraid this distinction between "inconsistent graph" and "graph containing ill-formed literals" is inevitable, in general.
> 
> I still don't see why.
> 
> > The problem is that you can not expect all RDF-consumming agents to know about all possible datatypes.
> 
> Right, you can't expect all agents to know about all datatypes, and neither should you. But...
> 
> > Consider:
> >
> >   @prefix : <http://example.org/ns/>
> >   :foo :prop "bar"^^:custom-datatype .
> >
> > If RDF-consistency depended on the well-formed-ness of the literal,
> > then a general-purpose RDF processor could simply not decide whether the above graph is consistent or not.
> > This would be embarassing...
> 
> Then consider this:
> 
>    :foo :prop "bar"^^:custom-datatype .
>    :prop rdfs:range rdfs:Literal .
> 
> Is this consistent or not, under D-entailment? A general-purpose RDF processor cannot decide, because it depends on the custom datatype...
> 
> How is this any less embarrassing than the case you mention?
> 
> In fact I don't think it's embarrassing. Any entailment regime that involves datatypes requires a *datatype map* as part of its definition. For types within the datatype map, it is well-defined whether literals are ill-typed or not. For types outside the datatype map, no special equivalences or entailments hold, and no inconsistencies are detected.
> 
> > That being said, recommending that all RDF processors MUST or SHOULD understand the semantics of the datatypes listed in the abstract syntax documents would certainly sound like a good idea, IMHO.
> 
> I'm not convinced that this would be a good idea. Some RDF processors simply push triples around and don't care about the semantics of datatypes. Others only need to understand the semantics of a few (e.g., SPARQL requires understanding the semantics of *some* but not all). Also, just a few months we've spent a lot of time making rdf:XMLLiteral optional, and I don't think we want to reverse that decision :-)
> 
> I think the current spec text is sufficient:
> 
> [[
> Specifications that conform to RDF may impose additional constraints on the datatype map, for example, require support for certain datatypes.
> ]]
> http://dvcs.w3.org/hg/rdf/raw-file/default/rdf-concepts/index.html#datatype-maps
> 
> Best,
> Richard
> 
> 
> >
> >   pa
> >
> >
> > On Fri, Nov 9, 2012 at 10:11 AM, RDF Working Group Issue Tracker <sysbot+tracker@w3.org> wrote:
> > RDF-ISSUE-109 (ill-typed-so-what): What's the consequence of a literal being ill-typed? [RDF Concepts]
> >
> > http://www.w3.org/2011/rdf-wg/track/issues/109
> >
> > Raised by: Richard Cyganiak
> > On product: RDF Concepts
> >
> > (Raising and issue on this for referencing in the upcoming new Concepts WD)
> >
> > What's the relevance of the distinction between “graphs containing ill-typed literals” and “inconsistent graphs” in the Semantics?
> >
> > The text stresses that the presence of an ill-typed literals does not constitute an inconsistency. But why does the distinction matter? Is there any reason anybody needs to know about this distinction who isn't interested in the arcana of the model theory?
> >
> > >From the perspective of someone who authors RDF data, or works with RDF data, they both seem like belonging to the same class of problem, and I'm a bit at a loss as to how to explain the difference.
> >
> > What should an implementation do? Should authors avoid generating such graphs? Should consumers reject it? Is an implementation that rejects ill-formed xsd:dates conforming?
> >
> >
> >
> >
> 
> 
>

Received on Monday, 12 November 2012 13:41:45 UTC