I've been thinking about how app developers will interact with silk floss. Having a triplestore where apps can save any data in a structured format seems great on the surface, but presents a privacy nightmare. While these objects will be wrapped in an activity object and presented as a stream, there is still some difficulty in protecting a user's privacy while also making apps interoperable. On one hand, apps should only be allowed to access data they have created. On the other, you may want to use more than one app with the same data.
Giving the user control over the data the app has access to seems rather sensible, but could become a huge problem depending on the app. If an app was only expecting the activity it created to be returned in a user's activity stream, and suddenly it starts returning all of the user's activity, that could be more data than it was prepared to handle and give the app access more to more than it actually needs.
SPARQL is the gold-standard of querying linked data. While the interface is certainly robust, this robustness comes at a cost of implementation. On the server side, the query would need to be transformed into SQL and permissions checked against the result, which could include aggregated fields. On the client side, few developers are familiar with SPARQL and how it differs from SQL. It has a significant learning curve which might be too great for most developers.
JSON-LD Framing on the other hand, isn't really designed as a query language. However, I don't see a reason why it couldn't be used like one. The format works like GraphQL in the sense that it lets the client describe what they want and how they want it. JSON-LD Framing could theoretically be used in a similar way. It's unfortunate that GraphQL doesn't work well with linked data, but sadly its strong-typing makes it nearly impossible to use well. JSON-LD Framing is far less robust than SPARQL, but appears to be faster to implement on the server and a has smaller learning curve for client developers.
A good workflow for clients could be to provide the framing as part of the OAuth 2 scopes. The user would then be able to see the frame with real examples of data that would be accessible to the app. The user could specify to limit the frame to only objects created by the app or to objects from any app that match the query. This gives the user control to limit the access the app has or to broaden it.
JSON-LD Framing could be extended with other features. Greater privacy could be achieved by forcing the app to declare all the fields they want exposed in the response. Flags could be added to declare what field the data should be ordered by and in what direction. Parameters could be added to make dynamic queries easier.
While this might be abusing JSON-LD Framing a bit, I think this is a good initial direction for the API for silk floss. Having an interface that is simple for me to implement and one that is somewhat familiar for developers seems like a win.