> On 2017-05-14, at 22:21, Paul Tyson <[email protected]> wrote: > >>>> […] >>>> >>>> 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.)
the document is not old. it refects recent work and is dated 10.5.2017 > I don't quite get the notion of "framing", yet, ... > > [but] 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. neither of your concerns, in itself, calls json-ld framing into question. best regards, from berlin, --- james anderson | [email protected] | http://dydra.com
