Open bourgeoa opened 3 years ago
Is the purpose of this proposal to make things easier within solid-file-client or with intention of rdf-query being a stand-alone package for other uses?
I don't think it will really make things easier within solid-file-client. Maybe more rdf like for acl.
My idea was somewhat different.
I feel we are missing easy ways to retrieve/write turtle fragments from webId card (/profile/card) and extended properties (privateTypeIndex.tll and publicTypeIndex.ttl) or to add friends or create groupAgents with the purpose to manage apps access to a pod's data. (simple follow your nose retrieve/write functions). The code cost should be low (?) but it changes the initial purpose of solid-file-client making it a more general solid-client with an orientation to make things easier.
Solid-file-client has all the elements to do it : rest-API, file management, acl management, easier N3 through rdf-query. PATCH and rdf-query may do the job. It can be investigated. A limitation is that PATCH is server side and the rdf-Query is client side.
May be it will be better to have a separate package for rdf content management including acl management, so it can be used by itself with fetch or with a different file manager. The only thing I do not really like is that N3 is used 2 times and that solid-file-client needs minimal turtle manipulation for container contents and acl (all copy/move and related like zip/unzip).
I have been thinking of implementing client-side patch in solid-rest. It would be non-atomic - read the file into the store, apply the patches to the store, save the store back to disk.
On Wed, Sep 30, 2020 at 10:37 AM Alain Bourgeois notifications@github.com wrote:
I don't think it will really make things easier within solid-file-client. Maybe more rdf like for acl.
My idea was somewhat different.
I feel we are missing easy ways to retrieve/write turtle fragments from webId card (/profile/card) and extended properties (privateTypeIndex.tll and publicTypeIndex.ttl) or to add friends or create groupAgents with the purpose to manage apps access to a pod's data. (simple follow your nose retrieve/write functions). The code cost should be low (?) but it changes the initial purpose of solid-file-client making it a more general solid-client with an orientation to make things easier.
Solid-file-client has all the elements to do it : rest-API, file management, acl management, easier N3 through rdf-query. PATCH and rdf-query may do the job. It can be investigated. A limitation is that PATCH is server side and the rdf-Query is client side.
May be it will be better to have a separate package for rdf content management including acl management, so it can be used by itself with fetch or with a different file manager. The only thing I do not really like is that N3 is used 2 times and that solid-file-client needs minimal turtle manipulation for container contents and acl (all copy/move and related like zip/unzip).
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/jeff-zucker/solid-file-client/issues/171#issuecomment-701537956, or unsubscribe https://github.com/notifications/unsubscribe-auth/AKVJCJF4QJ5FTAL2AGLXZILSINUEFANCNFSM4R5SXAMQ .
I feel it is a good idea. It can reuse an extended rdf-query with some code to convert application/update-sparql to turtle or text/n3.
@jeff-zucker rdf-query uses solid-namespace to query ttl files using N3. This is very convenient : example query(url, null, { acl: 'agent' })
To test PATCH has a valid text/n3 content, the query has been updated to also use text/n3.
As a enhancement I propose to add the following functions, that will allow to have a subset of N3 functions directly accessible to manipulate N3 store in browser :
parseUrl (url)
,parse (url, string, options)
create a cached store for urladdQuad (url, s, p, o, g)
add a quad to cached storeadd (url, turtle, options)
add quadsArray from turtle to cache(url) storeremoveMatches (url, s, p, o, g)
removed matching quads from cached storewrite (url, options)
andwriteQuads (quadsArray, options)
export to rdfWith the actual query (url, s, p, o, g) and queryTurtle (url, turtle, s, p, o, g) we have a subset of N3 using solid namespace