Malformed QPF with literal subject

[langsamu]

Malformed QPF with literal subject

[github-actions]

Thanks for reporting!

[jeswr]

Assuming you agree, I'd gladly try my hand at a first contribution, but I'd need some guidance. Unfamiliar as I am with the codebase, I naively think this might be as easy as a condition on the term type of the QPF request subject, if any.

It should be possible to implement this by adding a condition here which returns an empty set of quads if any of the terms do not match the expected term type (in particular you could enforce " The subject MUST either be a variable or an IRI; the predicate MUST either be a variable or an IRI; the object MUST either be a variable, an IRI, or a literal; the graph MUST either be a variable or an IRI").

To return an empty set of quads with the correct metadata you should use this logic. I would suggest refactoring that logic into a emptyWithMetadata function.

[rubensworks]

As of today, nothing I'm aware of prevents Comunica from working with generalized RDF.
As such, implementing the suggested change may restrict some valid use cases (e.g. querying over N3 files).

But the TPF spec does indeed make the explicit restriction, so we should handle at least that part.

I'm wondering if we should not go for a more high-level approach, and introduce a proper generalizedRdf option, which is false by default. And if false, we can modify our quadpattern query operation actor so that it always returns empty results when literals appear in non-object positions.
This would still enable users to force generalized RDF mode if they want to do so.

[jeswr]

I'm wondering if we should not go for a more high-level approach, and introduce a proper generalizedRdf option, which is false by default. And if false, we can modify our quadpattern query operation actor so that it always returns empty results when literals appear in non-object positions.

Just to clarify - do you mean implement this in addition to doing an explicit restriction in the case of the TPF/QPF spec. I think the in addition to part is important in order to allow use-cases such as querying over the union of a TPF/QPF endpoint and an N3 document.

[rubensworks]

do you mean implement this in addition to doing an explicit restriction in the case of the TPF/QPF spec

No, I was referring to just applying this restriction at a higher level. To avoid us having to implement the same restriction at different places.

I think the in addition to part is important in order to allow use-cases such as querying over the union of a TPF/QPF endpoint and an N3 document.

But then we would be mixing regular RDF with generalized RDF, and crossing two formal boundaries, which would probably open up another can of worms. We may want to avoid going into this, without knowing for certain that this is a valid use case.