Re: CONSTRUCTing illegal triples should be optional

On 31/07/12 18:00, David Booth wrote:
> Hi Andy,
>
> Thanks for your response.  I am not satisfied with this resolution.
> I see no harm that would be created by the simple wording change that
> I proposed -- NO implementation would have to change -- and I do see
> harm in the current wording.

An implementation of an RDF system capable of receiving results from a
SPARQL 1.0 engine would have to change to work with the same query in
the loose SPARQL 1.1 implementation.  It would require at least a new 
and specialised parser.

SPARQL 1.1 charter:
[[
All queries, that are valid in the January 2008 version of SPARQL,
should remain valid in the new version and should produce identical
results, except in the case of errata.
]]

Nothing stops an implementation emitting what it likes - but don't call
it SPARQL or RDF.

Elsewhere you argue that the SPARQL specification needs to exactly
define the behaviour of systems claiming compliance with the standard.
How do you reconcile these two positions?

 Andy

> This is similar to many other situations in which the specification
> should not force an implementation to perform strict validity
> checking that the user may not want or need, such as ensuring that
> all dynamically generated URIs are strictly conforming, all dates are
> valid, etc.  Strict validity checking is definitely a nice optional
> value-add for implementations that choose to provide it, when users
> want it.  But the specification (rightly) does not force every
> implementation to perform strict validity checking, and shouldn't in
> this case either.
 >
> The SPARQL spec cannot standardize exactly what should be output if
> the user CONSTRUCTs a triple having a literal as subject, but it
> doesn't need to: the result can be implementation defined, just as
> it is in other situations in which the user does something illegal.
> This has been a standard approach in programming language design for
> decades: if the user *chooses* to do something illegal, then the
> results are implementation defined.

> David
>
> On Tue, 2012-07-31 at 09:06 +0100, Andy Seaborne wrote:
>> David,
>>
>> Thank you for your comment about CONSTRUCT.
>>
>> SPARQL is defined to work with RDF and CONSTRUCT defined to create
>> RDF graphs by receiving an HTTP-carried request and returning the
>> results using one of the RDF concrete syntaxes.  The SPARQL
>> specification does not say anything about API use.  It is not in
>> the charter of the working group to define a new data framework
>> going beyond RDF.  SPARQL builds on the work of the RDF working
>> group.
>>
>> If an implementation wishes to go beyond the specification in some
>> way, such as allowing API use to create other forms of triples, it
>> is at liberty to do so, accepting responsibility for
>> interoperability issues this raises.  Interoperability is an
>> important aspect for a web system.
>>
>> The working group is not planning to make any changes in this
>> area.
>>
>> I would be grateful if you reply to this message to confirm that
>> the working group has responded to your comment.
>>
>> Yours, on behalf of the SPARQL Working Group,
>>
>> Andy
>>
>>
>> On 20/07/12 17:18, David Booth wrote:
>>> Regarding this: http://www.w3.org/TR/sparql11-query/#construct
>>> [[ If any such instantiation produces a triple containing an
>>> unbound variable or an illegal RDF construct, such as a literal
>>> in subject or predicate position, then that triple is not
>>> included in the output RDF graph. ]]
>>>
>>> This really bothers me, because: (a) it unnecessarily couples
>>> SPARQL to a controversial decision in the RDF WG that may well
>>> change in the future, i.e., the prohibition against literals as
>>> subjects; and (b) it forces a conforming implementation to
>>> perform checks that its user may not want or need.
>>>
>>> If a user chooses to generate invalid RDF then that is his/her
>>> business. The SPARQL spec should not prohibit it.  If a
>>> particular implementation offers the feature of performing this
>>> check, then that is fine.  But it is unnecessarily draconian to
>>> require all implementations to do it.
>>>
>>> I suggest changing the above to: [[ If any such instantiation
>>> produces a triple containing an unbound variable then that triple
>>> MUST NOT be included in the output RDF graph. Otherwise, if any
>>> such instantiation produces a triple containing any illegal RDF
>>> construct, such as a literal in subject or predicate position,
>>> then that triple MAY be excluded from the output RDF graph. ]]
>>>
>>>
>>
>>
>

Received on Tuesday, 31 July 2012 17:40:12 UTC