Re: support for ill-typed literal terms should remain a requirement

On Nov 1, 2024, at 1:15 PM, Gregg Kellogg <gregg@greggkellogg.net> wrote:
> 
> Ill formed literals from recognized datatypes can’t have an associated value by definition, and literals from un-recognized datatypes can’t have a value as the datatype is unrecognized anyway. The question is: is it reasonable for an implementation to drop triples containing ill formed literals with recognized datatypes. I don’t see the harm in requiring that they be retained in a graph even though there is no derived value, but I can see the argument for giving implementations allowance to drop them, and the expense of interoperabiity.

I think the potential harm is in systems that have specialized storage for recognized datatypes (likely for performance reasons). Requiring such systems to have a secondary storage location for ill-formed literals adds complexity not just in the storage system, but then also potentially in the query system as what was an optimized codepath to access those values turns into a more complex union of the optimized codepath and a fallback codepath to collect all the ill-formed literals.

I don’t mind systems that want to support such a design, but think it adds a pretty big burden on systems that want only the optimized codepath. It seems strange to me to write a spec that depends on other standards, and then force implementations to ignore the specifics of those other standards.

.greg

Received on Friday, 1 November 2024 20:28:06 UTC