Hi Laura, On Fri, 2017-05-12 at 09:45 +0200, Laura Morales wrote: > > I'm not sure I completely understand the use case that this approach is > > trying to address. But at best, it looks like a nonstandard, > > application-specific shortcut to produce something like a table with > > subrows. > > > Right now Jena returns 1 triple per line. For example > > - author-1 book-1 > - author-1 book-2 > - author-2 book-1 > .. > > instead of > > - author-1 > ---- book-1 > ---- book-2 > - author-2 > ---- book-1 > > the nested structure (second one) looks much more natural in the context of > graphs, like RDF. The first approach instead returns results like any other > RDBMS. This is a problem because even if it's true that traversing a graph > with SPARQL is very easy (something that would require a huge number of JOINs > in SQL), the returned data grows exponentially, in particular if you are > following several predicate links and want to return properties from nodes in > between. For every different value a new row is added to the results, so the > number of results is like "property1 x property2 x property3 x ..."
When you say "looks much more natural", you have a certain display structure or application use in mind. But what if I wanted it the other way (books with author subrows), or organized by other properties (say, year of publication, or number of pages), or multiple properties? How can the query engine know what semantics you want to apply to organize the results? And then when your application requirements changed, you would either have to write extra client-side code to re-organize the query results, or write an additional query just to get results in a different format. This is just not a good application architecture. SQL queries are the same way. There's no way to form a standard sql query to return "nested" results. You must resort to some procedural language, either client-side or server-side, to do that. There are all manner of tools and frameworks for SQL that pretend to make this easier, but under the covers they all use a declarative, logic-based query to get a (possibly un-normalized) result set, and then transform the result set to some "more useful" structure. I think most people on this list use and like jena because it lets them deal with RDF data in its natural state, according to the data exchange and processing standards that have been established by W3C. There are any number of nonstandard extensions that could be imagined, and as long as they don't interfere with the basic capabilities of jena, and people want to contribute the effort, that's great. Although I still don't know what sort of application you're building, I'm almost certain it would be better without relying on "nested JSON" results from jena. In my work I have successfully used 2 different approaches--and will probably explore yet a different approach next time. 1) When I process sparql-results in a servlet, I get srx results and transform with xslt. 2) When I process results in a browser with javascript, I get sparql-results+json and use grouping to handle unnormalized results. I have done some small prototyping using json-ld results from a CONSTRUCT query. It seems easy enough to do this on a small scale for a specific domain, but to do it generically requires better javascript libraries for navigating the graph structure represented by json-ld. My next non-trivial project involving display of RDF data will include some mix of json-ld, d3 [1], and probably SHACL or ShEx to define subgraphs of interest. Regards, --Paul [1] https://d3js.org/
