TSV Results parse skips empty bindings in result

[gweis]

Here is a failing test case, where a tsv result with possible optional bindings is being parsed, plus a proposed quick fix for it.

[joernhees]

i'm not that deep into pyparsing but somehow would've expected None instead of object() here... but then this way could cause less problems...

[gweis]

Yes, that’s what I thought as well, but pyparsing skips results that return None.
It is an internal protocol thing to show that a term didn’t match or so.

In general I think the TSV might be faster by using less pyparsing. E.g. split each line on tabs and parse each binding separately with something like from_n3(),
but this would require a bit more work to make it robust again. (I guess that’s something to discuss in some other thread).

The patch here is rather designed to have less impact on the way the parser works at the moment.

thanks,

Gerhard

On 5 May 2014, at 12:29, Jörn Hees notifications@github.com wrote:

In rdflib/plugins/sparql/results/tsvresults.py:

@@ -29,10 +30,16 @@
RDFLITERAL = Comp('literal', Param('string', String) + Optional(
Param('lang', LANGTAG.leaveWhitespace()
) | Literal('^^').leaveWhitespace(

•      ) + Param('datatype', IRIREF).leaveWhitespace()))
  

• ) + Param('datatype', IRIREF).leaveWhitespace()))

+NONE_VALUE = object()
i'm not that deep into pyparsing but somehow would've expected None instead of object() here... but then this way could cause less problems...

—
Reply to this email directly or view it on GitHub.

[joernhees]

thanks, seems good to me

[gromgull]

Thanks! Pyparsing is indeed slow - you can parse TSV much more quickly.

I would not give any guarantees for the existing from_n3 method - fixing it up would be a nice pull request :)

[gweis]

Agreed :)

from_n3 definitely needs some sort of validation or return errors in case a term is not valid. At the moment it accepts pretty much anything you throw at it and I believe it returns at least an empty “string” in case it couldn’t match anything.

might look into updating from_n3 in the next 2 weeks unless someone else is taking that over. I guess issue #192 is the place to discuss this further.

cheers

On 8 May 2014, at 4:50, Gunnar Aastrand Grimnes notifications@github.com wrote:

Thanks! Pyparsing is indeed slow - you can parse TSV much more quickly.

I would not give any guarantees for the existing from_n3 method - fixing it up would be a nice pull request :)

—
Reply to this email directly or view it on GitHub.