Is JSON-LD really necessary for large or incremental RDF sending? What about n-triples or, if you want to use a JSON format, what about HexTuples?
https://github.com/ontola/hextuples HexTuples was designed especially for this sort of task and very fast, triple-by-triple serialising and parsing. There is HexTuples support in RDFLib and we use it when APIs must talk JSON but do incremental or large things. It would be dead easy to implement it in Jena. Nick On Sat, Jul 13, 2024 at 12:25 AM, James Anderson <[anderson.james.1...@gmail.com](mailto:On Sat, Jul 13, 2024 at 12:25 AM, James Anderson <<a href=)> wrote: > good afternoon; > >> On 10. Jul 2024, at 07:36, Holger Knublauch <hol...@topquadrant.com> wrote: >> >> I am working on serializing partial RDF graphs to JSON-LD using the >> Jena-Titanium bridge. >> >> Problem: For Titanium to "see" the triples it needs to have a complete copy. >> See JenaTitanion.convert which copies all Jena triples into a corresponding >> RdfDatset. This cannot scale if the graph is backed by a database, and we >> only want to export certain triples (esp for Framing). Titanium's RdfGraph >> does not provide an incremental function similar to Graph.find() but only >> returns a complete Java List of all triples. >> >> Has anyone here run into the same problem and what would be a solution? > > yes, we have. > as we see cardinalities in the results from queries which qualify their > response media type with ld+json which are quite large, i have considered > ways to emit the results incrementally. > problematic is that, depending on the "embed" and "ordered" settings, it can > be necessary to materialize the results, before emitting any data. > if all references are just identifiers, incremental generation is possible. > if the query already orders the results - which may be possible without > sorting depending on the available indices, this is possible even if a > resource can appear just once. > if the results are not ordered, but the result is to be, then (as i recall > the framing recommendation), the document members must be sorted, which > requires to materialize all results. > >> >> I guess one solution would be an incremental algorithm that "walks" a >> @context and JSON-LD frame document to collect all required Jena triples, >> producing a sub-graph that can then be sent to Titanium. > > in which process - depending on the embedding constraints, the results may > have to have been materialized in order to ensure that the entire subgraph > has been seen. > >> But the complexity of such an algorithm is similar to having to implement my >> own JSON-LD engine, which feels like an overkill. >> >> Holger >> > > --- > james anderson | ja...@dydra.com | https://dydra.com
