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

Richard,

I'm not sure we are talking about the same thing, so I'll try to rephrase
how I understand your proposal, and then to rephrase my concerns.

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.

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.

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