Open bjdmeest opened 6 months ago
There are two things here. First, the second part, "R2RML processors are allowed to answer queries," seems to imply the virtual KG case where R2RML is used to rewrite SPARQL queries into SQL. RML has decided to "drop" the inverse expression clause as virtualization is a different "problem."
Secondly, I agree that IRI validation must be part of the functionality. And, I interpret R2RML as being "data validation is optional" (see data type validation, for example), but they are strict when it comes to absolute IRIs. I would even go as far as to take the paragraph from R2RML:
The term generation rules, applied to a value, are as follows: 1 If value is NULL, then no RDF term is generated. 2 Otherwise, if the term map's term type is rr:IRI: 2.1Let value be the natural RDF lexical form corresponding to value. >2.2If value is a valid absolute IRI [RFC3987], then return an IRI generated from value. 2.3Otherwise, prepend value with the base IRI. If the result is a valid absolute IRI [RFC3987], then return an IRI generated from the result. 2.4 Otherwise, raise a data error. [...]
I would not raise a data error but rather a generation error. This is my main problem with how R2RML handles this as their validation for data errors is optional but enforce IRI validation. Then we can easily distinct between both cases and it becomes way more clear that validation of the data itself is optional, but the generated output must honor valid IRIs, RDF compliance, etc.
In total agreement, except that I vote for extending 2.4 to either (i) raise a generation error (no output aka strict mode), or (ii) return NULL for invalid IRIs and continue (partial output aka lenient mode)
I'm not saying this needs to be fixed by yesterday though, there are more error-related issues that we can maybe all tackle together in a next iteration
In total agreement, except that I vote for extending 2.4 to either (i) raise a generation error (no output aka strict mode), or (ii) return NULL for invalid IRIs and continue (partial output aka lenient mode)
Oh yes 100% regarding strict or not.
I'm not saying this needs to be fixed by yesterday though, there are more error-related issues that we can maybe all tackle together in a next iteration
Exactly! This kind of discussions is what I wanted to spark by including the test-cases into the KGC Challenge. This way we finally implement something to see if it actually works and come across these kind of details. Thanks for tackling them together you all!
Technically, an easy fix would be to use error codes:
You can then have engines that still produce some RDF, but you know that when the error is 1, you can "ignore" or "discard" the output. When it is 2, you can still decide whether to use the data or not.
Speaking of error codes, maybe also one for an invalid input parameters e.g., mapping file, CLI args, etc. ?
I would suggest to have this in mind for working-group
but not incorporating it now in the spec. @bjdmeest @DylanVanAssche @chrdebru?
+1 for WG
R2RML states
but also
So, data validation (ie incoming data) is optional for [R2]RML engines and I agree with that.
Remaining question is: does that means that IRI validation (ie outgoing data) is optional? If it's not, every generated term should be validated (so increased processing time) to make sure the engine does not output invalid RDF If it is, and RML engine (whose sole purpose is to generate RDF) could generate invalid RDF.
I vote for 'IRI validation MUST be part of the functionality of an RML engine',
but that doesn't mean that individual engines cannot support 'lenient' modes to generate RDF-like strings faster, but without validation(I'm removing this last comment as it's out of scope).