Hi,
I am using Stardog Studio to perform some queries through a virtual graph into a postgres db. When I run the query, duplicate copies of the query are generated (usually offset by a few milliseconds). Does this impact query run times? Does this have something to do with querying through virtual graphs?
Thanks for the insight!
Kevin
Can you include the options you’ve created the database with. I could assume you’re using the same ones in your previous question but that’s probably not a good idea. Can you also include all the virtual graphs you may have added, the queries that are causing the problems and their query plans?
The studio problem seems to have solved itself... I was more just asking if this is the intended behavior or if it would impact query speeds/bandwidth.
@Kevin_Vanslette Glad to hear that your issue has resolved itself, but just wanted to follow up: there are some cases where Studio will intentionally run a query twice in order to get results back from Stardog in two different formats. For example, if you run a CONSTRUCT or DESCRIBE query from Studio, Studio will ask Stardog for the results in their standard format but also formatted as JSON-LD. This is so that Studio can quickly (without needing to query again) show you the results both as text in their standard format (e.g., as TriG) and as a visualized graph (which is driven by JSON-LD).
Any particular reason you didn’t just use a javascript lib to convert to avoid the second query? If it was because you needed a specific JSON layout and went insane trying to understand JSON-LD framing I would completely understand.
Some of it had to do with JSON layout (as you suggested); another factor, IIRC, was a limited number of options supporting transformation of TriG (let alone with RDF*-related things like edge properties) to JSON-LD.
It just occurred to me that it seems like you’d be most of the way to having what you need with the Millan parsers.