Hello all,
I am trying to use comunica for querying the data returned as a SolidDataset type, however it appears the engine takes types of IDataSource while the type returned from getSolidDataset is incompatible. Is there a better way to do this or am I doing something incorrectly?
Thanks
The IDataSource that Comunica accepts includes RDFJS sources; you can convert a SolidDataset to an RDFJS data source using the toRdfJsDataset function in @inrupt/solid-client.
In case you didn’t already know; Comunica also has a Solid Engine so you can query over permissioned data without needing to first retrieve it yourself using getSolidDataset from @inrupt/solid-client. Instead you can just pass a session created with @inrupt/solid-client-authn-* to the query engine.
In general this is going to be the faster & cleaner approach for most use cases.
@jeswr Out of curiosity, can the Solid Engine also receive (or is planning to) GraphQL-LD queries? That would be a game changer, as far as usability, and Communica has compellingly demonstrated that approach on their website.
Yes the Comunica frameworks supports GraphQL-LD queries and it is just a matter of configuring an engine with this actor. This is such a build graphql-ld-comunica-solid - npm but that it is still based on Comunica V1 components so if you want to use it I would create a new configuration for Comunica V2.
There is also more GraphQL work on the way (which is fully compliant with the GraphQL spec and does not require JSON-LD contexts).
Okay, I think I’m looking more at JSON-LD for use with Solid, but out of curiosity, how would official spec Graph-QL handle the namespaces for the data elements (are they just declared inline in the plain JSON following this method: RDF 1.1 JSON Alternate Serialization (RDF/JSON))? Thanks!
And the other think I’m wondering is, perhaps other than LDP Collection handling, would GraphQL-LD be able to do everything that LDP does for Solid Project? And with GraphQL mutations, why not also perform operations on LDP Collections as well?
but out of curiosity
I’ll keep this thread updated with details soon
why not also perform operations on LDP Collections as well?
I would recommend reading the What's in a Pod? pre-print. In a GraphQL abstraction we would be more interested in targeting the Graph-centric interpretation of a Pod, rather than the Document-centric interpretation. In particular, this allows developers to perform mutations on data in their Pod without having to themselves consider which LDP container & document it should be placed in.
@jeswr , okay that makes sense. I had never thought of collections as
document folders, as opposed to graphs, but now I am beginning to. So no
need for GraphQL accessors for collections. Thanks, by the way, and I’ll
check out the pre-print.
@jeswr I just read the “What’s in a Pod?” piece. My first reaction was that I had naively assumed that Solid Pods had already fully embraced the graph-centric interpretation. Now I see that more work needs to be done, to achieve the trust, access control policy, provenance, etc. features required to make Pods achieve their original goals. Is there a code branch or wiki page for Solid Project working to implement the graph-centric interpretation within Solid Pods? Thank you!
Though not specific to the graph-centric vision; the main opensource work that I can point you to around at the moment is the work of SolidLab and some of the Research Challenges that are being tackled.