On Sun, 2017-05-14 at 17:56 +0000, james anderson wrote: > good evening; > > > On 2017-05-14, at 19:30, Paul Tyson <phty...@sbcglobal.net> wrote: > > > > 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. > > this concern is addressed by json-ld framing: > http://json-ld.org/spec/latest/json-ld-framing/ > Well, yes, and for OP's purpose this might fit. (Although I see this document is several years old and I don't find anything current about it.) I don't quite get the notion of "framing", yet, but the opening statement of the referenced document worries me on several counts:
"JSON-LD Framing allows developers to query by example and force a specific tree layout to a JSON-LD document." The idea of "forcing" a specific tree layout on a graph serialization format seems to violate some fundamental principle of data modeling, and leaves one with a muddy stew of content, structure, and presentation that can only make application development more difficult. Now, there are well-understood algorithms for transforming between graph and tree data structures, and--in the abstract--this is what happens somewhere in the toolchain between a sparql endpoint and an HTML (or any other format) document. But ideally this process should be 1) as direct as possible, involving the fewest necessary transformations; and 2) informed by the semantics of the application. These 2 requirements point up the need for a general-purpose RDF graph transformation language, not tied to any particular exchange syntax. Regards, --Paul
