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

> On 1. Nov 2024, at 21:15, Gregg Kellogg <gregg@greggkellogg.net> wrote:
> 
>> On Oct 31, 2024, at 3:20 PM, James Anderson <anderson.james.1955@gmail.com> wrote:
>> 
>> good evening;
>> 
>> with respect to the discussion of the recommendation's requirement for support of ill-typed terms [1], please record a change to my sentiment.
>> when i discussed the vote with thomas after the call, he corrected my understanding of the purpose of a "straw pole", in that the customary effect is to record an effectively final decision.
>> i had misunderstood it to be just a milestone along the path of still ongoing deliberations.
>> in the situation where the outcome constitutes a working group decision, my vote should be recorded as "-1".
> 
> Straw Polls are a poll of the general feelings of the group and do not settle issues.

However, as far as my experience reaches - which is NOT very far indeed - even straw polls are very seldomly performed twice if the result seems rather clear. That's why I hinted at James that he might reconsider his vote.
 
> That would be done with a RESOLUTION in the minutes. Note that Resolutions are also not final until the specs are published as Recommendations; they can be revisited if there is new evidence that might change the determination of group members.
> 
> Traditionally, a “-1” vote on a resolution (not straw poll) implies a Formal Objection, although I think this practice is fading and groups sometimes make decisions where this is not 100% consensus across the membership.
> 
>> the consequence for both interoperability and utility is sufficiently significant that support should be retained as a conformance requirement.
>> if a change is to be made to recommendations, it should be to characterize the nature of "support".
>> the essential requirement should be that all terms - even ill-typed terms, are "first class".
>> by analogy to the source of that concept, this means that it should be possible to incorporate them into graphs, to manipulate them through graph store protocol operations, and to rely on their identity for matching and binding in basic graph patterns and for algebra operations .
>> 
>> this does not mean that all sparql operators must succeed if applied to such terms.
>> it could even be that the results of such operations is specified to be undefined.
>> it just means that a graph store must be transparent with respect to them and be able to pass them through intact as opaque terms.
> 
> 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.

But interoperability is a main concern of the semantic web, not optimization of implementations. Of course there’s wiggle room in the details, and also requirements that encourage or even demand the removal of defective data (e.g. in entailment). OTOH ill-typed literals also are not per se without value: the literal itself might still make sense to a human reader even if wrongly typed. 

As I said in the call I would interpret an implementation that sorts out ill-typed literals but keeps them around for further inspection (e.g. stores them in a separate graph and notifies the user) as conforming.


Thomas

> Gregg
> 
>> not to do this will compromise severely the ability of rdf to represent and exchange information and diminish its standing as a medium for data integration.
>> 
>> best regards, from berlin,
>> ---
>> [1]   Drop the requirement to support ill-typed literals with recognized datatype IRIs <https://www.w3.org/2024/10/31-rdf-star-minutes.html#783b>
>> ---
>> james anderson | james@dydra.com | https://dydra.com