本文整理汇总了Java中com.hp.hpl.jena.graph.TripleMatch.asTriple方法的典型用法代码示例。如果您正苦于以下问题：Java TripleMatch.asTriple方法的具体用法？Java TripleMatch.asTriple怎么用？Java TripleMatch.asTriple使用的例子？那么恭喜您, 这里精选的方法代码示例或许可以为您提供帮助。您也可以进一步了解该方法所在类com.hp.hpl.jena.graph.TripleMatch的用法示例。
在下文中一共展示了TripleMatch.asTriple方法的3个代码示例，这些例子默认根据受欢迎程度排序。您可以为喜欢或者感觉有用的代码点赞，您的评价将有助于系统推荐出更棒的Java代码示例。
示例1: graphBaseFind
import com.hp.hpl.jena.graph.TripleMatch; //导入方法依赖的package包/类
@Override
public ExtendedIterator<Triple> graphBaseFind(TripleMatch m) {
checkOpen();
Triple t = m.asTriple();
if (log.isDebugEnabled()) {
log.debug("Find: " + PrettyPrinter.toString(t, getPrefixMapping()));
}
FindQuery query = new FindQuery(t, mapping.getTripleRelations(),
new ExecutionContext(mapping.getContext(), this, null, null));
ExtendedIterator<Triple> result = TripleQueryIter.create(query.iterator());
result = result.andThen(mapping.getAdditionalTriples().find(t));
return result;
}
示例2: graphBaseFind
import com.hp.hpl.jena.graph.TripleMatch; //导入方法依赖的package包/类
@Override
public ExtendedIterator<Triple> graphBaseFind(TripleMatch m) {
checkOpen();
Triple t = m.asTriple();
if (log.isDebugEnabled()) {
log.debug("Find: " + PrettyPrinter.toString(t, getPrefixMapping()));
}
FindQuery query = new FindQuery(t, mapping.compiledPropertyBridges(), null);
ExtendedIterator<Triple> result = TripleQueryIter.create(query.iterator());
if (mapping.configuration().getServeVocabulary()) {
result = result.andThen(mapping.getVocabularyModel().getGraph().find(t));
}
return result;
}
示例3: and
import com.hp.hpl.jena.graph.TripleMatch; //导入方法依赖的package包/类
/**
Answer an ExtendedIterator returning all the triples from this store that
match the pattern <code>m = (S, P, O)</code>.
<p>Because the node-to-triples maps index on each of subject, predicate,
and (non-literal) object, concrete S/P/O patterns can immediately select
an appropriate map. Because the match for literals must be by sameValueAs,
not equality, the optimisation is not applied for literals. [This is probably a
Bad Thing for strings.]
<p>Practice suggests doing the predicate test <i>last</i>, because there are
"usually" many more statements than predicates, so the predicate doesn't
cut down the search space very much. By "practice suggests" I mean that
when the order went, accidentally, from S/O/P to S/P/O, performance on
(ANY, P, O) searches on largish models with few predicates declined
dramatically - specifically on the not-galen.owl ontology.
*/
public ExtendedIterator<Triple> find( TripleMatch tm )
{
Triple t = tm.asTriple();
Node pm = t.getPredicate();
Node om = t.getObject();
Node sm = t.getSubject();
if (sm.isConcrete())
return new StoreTripleIterator( parent, subjects.iterator( sm, pm, om ), subjects, predicates, objects );
else if (om.isConcrete())
return new StoreTripleIterator( parent, objects.iterator( om, sm, pm ), objects, subjects, predicates );
else if (pm.isConcrete())
return new StoreTripleIterator( parent, predicates.iterator( pm, om, sm ), predicates, subjects, objects );
else
return new StoreTripleIterator( parent, subjects.iterateAll(), subjects, predicates, objects );
}