Currently, there are two ways to resolve (possibly relative) terms agains a base IRI:
base.join for one-shot operations,
base.batch_join for multiple operations.
The rationale for this design is that joining requires the structure of the base IRI to be parsed, and we do not store that structure in IRI Terms (to save space -- not all IRIs in a graph are expected to be used as base IRIs). batch_join allows to perform the parsing only once, and resolve multiple terms in a row.
A possibly better design would be to have a dedicated type, storing the parsed structure of an IRI, and providing methods to resove terms (and why not, whold triples, quads, or even graphs and datasets?). Term::batch_join would then be replaced by a Term::to_base method, returning such an object. This would allow for this kind of pattern:
let base = some_iri_term.to_base();
let abs_triples = some_triple_source.map_triples(|t| base.join_triple(&t));
Currently, there are two ways to resolve (possibly relative) terms agains a base IRI:
base.join
for one-shot operations,base.batch_join
for multiple operations.The rationale for this design is that joining requires the structure of the base IRI to be parsed, and we do not store that structure in IRI Terms (to save space -- not all IRIs in a graph are expected to be used as base IRIs).
batch_join
allows to perform the parsing only once, and resolve multiple terms in a row.A possibly better design would be to have a dedicated type, storing the parsed structure of an IRI, and providing methods to resove terms (and why not, whold triples, quads, or even graphs and datasets?).
Term::batch_join
would then be replaced by aTerm::to_base
method, returning such an object. This would allow for this kind of pattern: