Java Jena-写入owl文件-意外结果

我创建了一个文件系统，将文件和文件夹的元数据存储在owl文件中

对于文件系统，我使用FUSE的java绑定，即FUSE-JNA

对于OWL，我使用Jena：

最初，我的文件系统运行正常，没有错误。但过了一段时间，我的程序停止读取.owl文件并抛出一些错误。其中一个错误如下：

读取.owl文件时出错：

SEVERE: Exception thrown: org.apache.jena.riot.RiotException: [line: 476, col: 52] The value of attribute "rdf:about" associated with an element type "File" must not contain the '<' character.
org.apache.jena.riot.system.ErrorHandlerFactory$ErrorHandlerStd.fatal(ErrorHandlerFactory.java:136)
org.apache.jena.riot.lang.LangRDFXML$ErrorHandlerBridge.fatalError(LangRDFXML.java:252)
com.hp.hpl.jena.rdf.arp.impl.ARPSaxErrorHandler.fatalError(ARPSaxErrorHandler.java:48)
com.hp.hpl.jena.rdf.arp.impl.XMLHandler.warning(XMLHandler.java:209)
com.hp.hpl.jena.rdf.arp.impl.XMLHandler.fatalError(XMLHandler.java:239)
org.apache.xerces.util.ErrorHandlerWrapper.fatalError(Unknown Source)
org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source)
...

---

请指导我如何修复Jena的2号和3号蓝色突出显示错误。

您的方法存在输入卫生问题。我不能确定您的输入数据是否无效，但它确实应该在任何以编程方式构造URI或文本的方法中进行测试

URI

例如，以下两行是危险的，因为它们可以允许URI中不允许的字符，或者允许不能序列化为XML的文本值使用字符

Resource resource = model.createResource(resourceURI);
resource.addProperty(model.createProperty(baseURI+propertyName), model.createLiteral(propertyValue));

要解决URI问题，请使用

urlcoder

清理URI本身：

final String uri  = URLEncoder.encode(resourceURI, "UTF-8");
final String puri = URLEncoder.encode(baseURI+propertyName);
final Resource resource = model.createResource(uri);
resource.addProperty(model.createProperty(puri), model.createLiteral(propertyValue));

为了测试有问题的usuri，可以使用Jena的

IRIFactory

类型来验证所构建的URI是否符合某些特定规范

文字量

要解决文字的问题就有点棘手了。您不会得到一个异常，表明您的文本值不正确，但为了完整性，我将包含它（这样您可以清理所有输入，而不仅仅是现在可能导致问题的输入）

Jena的作者在将文本序列化为XML之前不会测试它们的值。他们用来检测无效XML字符的模式只关注作为RDF XML规范一部分需要替换的字符。Jena将最终验证（和异常抛出）委托给底层XML库。这是有意义的，因为将来可能存在一种RDF序列化，它允许所有字符的表达式。我最近被它咬了一口（例如，一个包含退格字符的字符串），所以我创建了一个更严格的模式，以便在运行时急切地检测这种情况

final Pattern elementContentEntities = Pattern.compile( "[\0-\31&&[^\n\t\r]]|\127|[\u0080-\u009F]|[\uD800-\uDFFF]|\uFFFF|\uFFFE" );
final Matcher m = elementContentEntities.matcher( propertyValue );
if( m.find() ) {
    // TODO sanitise your string literal, it contains invalid characters
} 
else {
    // TODO your string is good.
}

---

#3“admi”处截断的性质让我认为，这可能是底层数据传输和存储的问题，与XML、RDF、Jena或这一级别的任何其他内容无关。可能是一个被忽略的异常？

我的主程序有时将

resourceURI

参数作为空/空传递给

setDataTypeProperty

方法。这就是它制造问题的原因

因此，我修改了代码，并在方法的开头添加了两行：

    public void setDataTypeProperty(String resourceURI, String propertyName, String propertyValue) //create new data type property. Accept four arguments: URI of resource as string, property name (i.e #hasPath), old value as string and new value as string.
{
    if (resourceURI==null)
    return;
...
...

---

现在我已经运行了几天了，但是还没有遇到上面提到的错误。

文本中的突出显示很好，但是图像也很小。请把重要的文本复制粘贴到问题中。你能提供一个我们可以用来重现问题的答案吗？你提供了相关的代码，这很有帮助，但是你能提供一个完整的工作示例来重现这种行为吗？@JoshuaTaylor你是对的，文本应该在问题中。不过，作为一种短期解决方法，您可以（至少在Firefox中）右键单击图像并选择

查看图像

，以查看更大版本的图像。放大后，图像的分辨率足以阅读。您的文本中是否有任何意外字符可能不会显示在您向我们展示的编辑器中？也许是一个？你有没有办法猜测在#3-“爱慕”之后少了多少？或者它甚至可能被复制？还有w/r/t#2：你知道它应该放在哪个文件上吗？我最近被它咬了一口（例如，一个包含退格字符的字符串），我刚开始想知道它是否作为回车符返回。或者更有趣的是，我正在根据OP的用户名和问题中的一些文本，做出一些可能的假设，如果文本中可能存在错误。

    public void setDataTypeProperty(String resourceURI, String propertyName, String propertyValue) //create new data type property. Accept four arguments: URI of resource as string, property name (i.e #hasPath), old value as string and new value as string.
{
    if (resourceURI==null)
    return;
...
...