我在SPARQL构建查询,这是有用检索有关合同的细节:如何使用一个CONSTRUCT构建关于某些个人的RDF图?
CONSTRUCT {
?contract dcterm:identifier ?id .
?contract rdfs:label ?label .
?contract pc:bidder ?bidder .
}
WHERE {
OPTIONAL {
?contract dcterm:identifier ?id .
}
OPTIONAL {
?contract rdfs:label ?label .
}
OPTIONAL {
?contract pc:tender ?tender .
?tender pc:bidder ?bidder .
}
}
我有合同的列表,例如PC:C1,邮编:C2,我想在一个检索单个查询(或单个HTTP调用)两者的细节。
的第一个想法是每个URI来代替合同变量,并避免其他变量之间的冲突:
CONSTRUCT {
pc:c1 dcterm:identifier ?id1 .
pc:c1 rdfs:label ?label1 .
pc:c1 pc:bidder ?bidder1 .
pc:c2 dcterm:identifier ?id2 .
pc:c2 rdfs:label ?label2 .
pc:c2 pc:bidder ?bidder2 .
}
WHERE {
OPTIONAL {
pc:c1 dcterm:identifier ?id1 .
}
OPTIONAL {
pc:c1 rdfs:label ?label1 .
}
OPTIONAL {
?pc:c1 pc:tender ?tender1 .
?tender1 pc:bidder ?bidder1 .
}
OPTIONAL {
pc:c2 dcterm:identifier ?id2 .
}
OPTIONAL {
pc:c2 rdfs:label ?label2 .
}
OPTIONAL {
?pc:c2 pc:tender ?tender2 .
?tender2 pc:bidder ?bidder2 .
}
}
的问题是,有许多的URI查询可能变得相当大。
是否有更紧凑的写法呢?
我尝试使用IN运算符(https://www.w3.org/TR/2013/REC-sparql11-query-20130321/#OperatorMapping - 17.4.1.9),但Virtuoso似乎没有解析查询。 VALUES关键字(https://www.w3.org/TR/2013/REC-sparql11-query-20130321/#inline-data)似乎是一个很好的解决方案,但是Jena似乎没有正确解析它。
哪个Jena版本不起作用? – AKSW