W3C home > Mailing lists > Public > public-rdf-wg@w3.org > November 2012

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

From: Pierre-Antoine Champin <pierre-antoine.champin@liris.cnrs.fr>
Date: Mon, 12 Nov 2012 15:41:08 +0100
Message-ID: <CA+OuRR-6q6geLszKvh8SpzGFvFh+e4p2AO-C6v0-fSkR2u1WBQ@mail.gmail.com>
To: Richard Cyganiak <richard@cyganiak.de>
Cc: RDF Working Group <public-rdf-wg@w3.org>
Aaahhh... I got it now. I was indeed confused...

Part of the problem came from the fact that I was assuming that

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

was actually XSD-inconsistent... :-/
(so I was assuming that you are refering to RDF-inconsistency)

I understand your concern now, and I (obviously) concur:
I don't see the point of keeping this disctinction...

  pa



On Mon, Nov 12, 2012 at 2:41 PM, Richard Cyganiak <richard@cyganiak.de>wrote:

> 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 14:41:36 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:25:52 GMT