I've been playing around with BITES and permissions. I haven't had a chance to mess with user permissions too much since I'm working with a database that is used exclusively by myself.
Without named graph permissions BITES is like the wild wild west. Anyone can do anything to anybody so I assumed that it might set the permissions on a named graph added through bits to read/write for the user who added it and maybe read only for everyone else. If named graph security is enabled I get the following for any user other than admin when adding a doc
User can't modify some of the graphs in the query
Ok, maybe it needs to be given permission before adding it.
stardog-admin user grant -a write -o named-graph:tesst\\tag:stardog:api:docs:test:test2 zcw100
No luck there, still denied.
While I'm on the subject of bites, it took me a second to realize that the reason it's put/delete and add/delete is because it's mirroring the http request type.
It would also be nice if the resource types were in the help pages. It's in the docs but kept messing it up at the cli because I couldn't remember what the named graph resource name was
stardog-admin user grant -a write -o graph:test\tag:stardog:api:docs:test:test2 zcw100
nope
stardog-admin user grant -a write -o namedgraph:test\tag:stardog:api:docs:test:test2 zcw100
nope
stardog-admin user grant -a write -o named-graph:test\tag:stardog:api:docs:test:test2 zcw100
ahhh that's it. Not a big deal just a nice to have. Mabe the same with the single letter for permission
CDRWGKX
K? oh ya, that must be revoKe. Easy enough to figure out but it might be nice to have in the help page.
It would be really cool if there was a content addressable storage mode for BITES. BITES is already storing the file as what appears to be a UUID. If you stored it by SHA1 you'd have to do some reference counting when deleting but I don't image that it would be very difficult for Stardog to do.