使用dotnetRDF-rdfparseeException查询dbpedia sparql端点

在使用（dotnetRDF）

VDS.RDF.query.SparqlRemoteEndpoint.QueryWithResultSet（）执行以下查询时，一切正常

SELECT ?film ?p ?o
WHERE {
    ?film <http://purl.org/dc/terms/subject> <http://dbpedia.org/resource/Category:Japanese_films> .
    ?film ?p ?o
}
limit 500

我有RdfParseException和消息

"[Line 456 Column 29] Unexpected Character (Code 8211) – was encountered"

我尝试为ResultsAcceptHeader和RdfAcceptHeader属性设置值，但没有成功

如果在第二次查询中，我将限制从500更改为100，则效果良好

SELECT ?film ?p ?o
WHERE {
    ?film <http://purl.org/dc/terms/subject> <http://dbpedia.org/resource/Category:Japanese_films> .
    ?film ?p ?o
}
limit 500

你能帮我吗


现在，若limit的值为456，则抛出异常。
[第495行第25列]遇到意外字符（代码8211）
，这是第495行
ns19:？？？5555.
。第25列中的值为
\uu

这里有wiki格式的数据，我想，
dbpprop:kanji
属性的值有问题(インターステラ5555）
DBPedia已知编码问题，可能只是DBPedia产生了无用数据

要在dotNetRDF中对此进行进一步调试，您可以尝试使用以下代码包装调用查询的代码：

try
{
   Options.HttpDebugging = true;
   Options.HttpFullDebugging = true;

  //Try your query here
}
finally
{
   Options.HttpDebugging = false;
   Options.HttpFullDebugging = false;
}

这将导致解析失败（出现另一个错误），但会将原始HTTP响应转储到控制台进行调试。如果您可以编辑您的问题以包含转储文件第456行周围行中的内容，那么人们可以为您提供更多帮助

编辑

因此，正如人们所怀疑的那样，问题确实在于DBPedia生成的是无用数据，而不是dotNetRDF本身

当我下载了您提到的Turtle格式的文件并试图对其进行解析时，我收到了相同的错误消息，它与以下行有关：

ns6:Avalon_–_Spiel_um_dein_Leben ,

乍一看，这可能是有效的（因为前缀名称中允许使用简单的连字符
-
），但问题是它不是连字符，实际上是字符代码8211（AndyS提到的十六进制2013），这不在前缀名称字符的可接受范围内

顺便说一句，我也用Jena的Turtle解析器确认了这一点，只是为了确保它确实不是dotNetRDF问题

因此，基本上DBPedia数据是坏的，您可以通过适当地设置accept头来强制它将RDF/XML或NTriples发送回您，但是不能保证数据不会以这些格式返回。我建议您联系DBPedia的人员，将此报告为bug-DBPedia-discussion@lists.sf.net查看第456行会很有用。尝试使用wget发出请求（它对URL进行编码，而curl不编码，这样可以更容易地从命令行使用）

Unicode代码点8211为EN破折号（十六进制2013）

构造中的限制是图形模式中的行数，而不是构造模板。你可能会得到更多的三倍，这是所涵盖的选择。。。限制。尝试在SELECT中设置一个更大的限制，看看它是否会被打破。
如果我将限制更改为不同的值，服务器将返回不同的数据（可能它缓存了一些查询结果）。现在它适用于限制500、900、1000或455，但不适用于限制456。我已根据您的其他信息更新了我的答案，问题是来自DBPedia的坏数据实际上与汉字脚本无关。我已尝试应用此解决方案，但还不是很有启发性。