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.
Regards,
Holger
On Aug 24, 2008, at 12:01 PM, Norman Walsh wrote:
> Holger Knublauch <holger@knublauch.com> 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 <ndw@nwalsh.com> | Two starving men cannot be twice as
> http://nwalsh.com/ | 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

AltStyle によって変換されたページ (->オリジナル) /