Thanks, that should be helpful.
> On May 19, 2025, at 8:34 AM, Justin <[email protected]> wrote:
>
> Hey Jim,
>
> You might find the sparql anything code base as a useful reference. It also
> operates over virtual endpoints and it can avoid materializing based on
> triple pattern filtering.
>
>
> https://github.com/SPARQL-Anything/sparql.anything
>
>
> On Sat, May 17, 2025, 9:23 AM Andy Seaborne <[email protected]> wrote:
>
>> Jim,
>>
>> If you want to extend the execution of SPARQL, then look OpExecutor.
>> This is the place that SPARQL algebra become a stream of results.
>>
>> TDB2 extends this for its join support - TDB execution works on internal
>> 64 bit ids, not the full RDF term representation.
>>
>> TDB2 also delays turning ids back into RDF terms. For an operation like
>> "count" all that is need is the row (BindingTDB), not the values of each
>> cell of the row.
>>
>> Andy
>>
>> On 16/05/2025 21:41, Jim Balhoff wrote:
>>> Hi,
>>>
>>> I would like to provide a SPARQL endpoint over a virtual dataset. For
>> the IRIs in the dataset, I can compute anything known about them based on
>> the IRI itself. So rather than materializing the whole thing, I want to
>> just respond to triple pattern queries and generate the data on the fly. I
>> can see how I might implement the Model or Graph interfaces to support
>> this, but wondering if there is another API I should use that would be most
>> efficient for backing a SPARQL endpoint. For example, I could calculate
>> counts for particular triple patterns without iterating through all the
>> results. Or as another example I could imagine implementing certain joins
>> involving two triple patterns more efficiently than by generating the data
>> for both.
>>>
>>> Thank you,
>>> Jim
>>>
>>
>>
