Re: rdf in xproc

Hi Norm,

in principle I agree and it would be great if someone (standard or  
not) would add such operators to XProc. Such an approach will have  
some limitations though. Beside the obvious performance problems of  
unnecessary parsing and serializing, the approach you outline would  
simply not scale when one of the triple sources is an RDF database  
that doesn't fit into memory. Pipeline languages like SPARQLMotion  
(and I assume DERI's pipes language) operate on RDF APIs that abstract  
away the storage layer. We are using Jena as a triple source API and  
the code doesn't care where the triples come from physically. So if  
someone feeds a SPARQLMotion script with a database (e.g. via D2RQ)  
then the engine will only load those triples that it needs to see.  
This is particularly relevant when you try to chain together a steps  
including an inference engine. Only certain triples are relevant for  
the inference engine, so all others can be ignored and left on the  
database hard disc.


On Aug 24, 2008, at 12:01 PM, Norman Walsh wrote:

> Holger Knublauch <> writes:
>> Having said this I very much agree with Paul's statement that having
>> some standard pipeline facilities for RDF would be good thing. I  
>> would
>> even take it further and claim that for certain application areas RDF
>> might be a better starting point for a pipeline system than XML. In
> If you defined a set of RDF-aware steps for XProc, there's nothing
> about XProc that would constrain their flexibility to exchange triples
> and operate on graphs. True, the output of one step would flow into
> the input of the next as RDF/XML, but that would transparent to the
> steps themselves.
>                                        Be seeing you,
>                                          norm
> -- 
> Norman Walsh <> | Two starving men cannot be twice as
>            | hungry as one; but two rascals can be
>                              | ten times as vicious as one.--George
>                              | Bernard Shaw

Received on Sunday, 24 August 2008 19:14:16 UTC