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: Richard Cyganiak <richard@cyganiak.de>
Date: Sun, 11 Nov 2012 12:29:03 +0000
Cc: RDF Working Group <public-rdf-wg@w3.org>
Message-Id: <A3663891-95AB-4DD6-BE0C-29E1EDB15BE3@cyganiak.de>
To: Pierre-Antoine Champin <pierre-antoine.champin@liris.cnrs.fr>
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 Sunday, 11 November 2012 12:29:35 GMT

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