@Otto-AA oh sorry right, i did mis read your questions. Yes, multiple
acl:accessTo statements about the same authorisation node are possible, but what matters is that you check whether or not the authorisation node gives access to the resource from which you followed the link. So if you look at /folder/ and see a link header that points you to /.one-big-acl-doc then you need to look only at authorisation nodes in there that have #node acl:accessTo </folder/>, and not to any other authorisation nodes that may exist in that /.one-big-acl-doc
i’ll copy that answer to the issue
sorry that i hadn’t answered them earlier! :)
@namedgraph_twitter re https://gitter.im/solid/solid-spec?at=5d7ff6712e8fd94630e4817a , you're right but that doesn't mean that it can't be squatted for the time being :) ns/auth/acl is not necessarily "complete" by any sense or formally referred to in any W3C (or other) spec as far I'm aware. So, there is no reason why it can't be updated to include things like trustedApp or not. Whether trustedApp is a good/bad idea is a separate issue and we can address that through open discussion and implementation experience. Clearly there is some interest (a the very least) to know what's a "trusted" app. And the notion of "application" is not something entirely unique to Solid either. It is virtually everywhere. Again, we can discuss its semantics and what it all entails. Would you like to chime through the Solid panels? If you have technical concerns about it, it'd really valuable to know and have it documented so that we can have a better understanding.
@namedgraph_twitter If there isn't an issue for https://gitter.im/solid/solid-spec?at=5d7ff71b62bfc95112fe042e can you please create it? Perhaps in https://github.com/solid/process/blob/master/panels.md#app-authorization 's repo or https://github.com/solid/vocab is fine too I think.
if it should be discussed, it should be on a W3C forum
not unilaterally on Solid's wiki
and i'm pretty confident that while the ACL terms are widely used, Solid-introduced ones such as
trustedApp are not, because they address much more specific, and likely orthogonal issue, than the ACL terms
@namedgraph_twitter I don't believe "Solid" has authority over it. W3C (Team) or any group (usually WG, CG, but not strictly!) coordinating with them can probably update the ns. It is used out there I suppose but I would suspect that people are trusting it as they do with any other ns under w3.org. That is, things can change.
Like I said, trustedApp can find a home, but please raise it somewhere so it is properly tracked. Discussing it in chats is not going to change anything.
And the the term being squatting for the time being has no official stance whatsoever. The ACL vocab does not currently contain traustedApp so I wouldn't worry about it.
Aside: I don't think "trustedApp" is so far out that it doesn't belong in the ACL vocab either. I've seen worse.
i can do a PR for the
web-access-control-spec re. trustedApp namespace
but i'm not gonna look for and replace all its usages
hmm, I'll move this to the new chat room :D
It came from here; https://github.com/linkeddata/warp
I am going to pimp it out a little, if thats even possible but, I think I can.
take a piece from here and a piece from there, that sort of thing so, it requires me to become familiar with almost everything working with solid currently.
I am thinking that there are several apps I would like to use from one location, so Iframe's really make great use of combining applications in one place. Something like https://index.inrupt.net/
@JordanShurmer re https://gitter.im/solid/solid-spec?at=5daf9ff914d55a37855abf5d , LDP describes behaviour for the most part optional. Solid will set specific constraints and clarify or strengthen the requirements from LDP. For example, LDP doesn't require any specific type of container to be implemented however it prescribes how they should behave if adopted. See also solid/specification#47 for containers for the upcoming Solid spec.
Anyone interested in an opensource project?
Spec oriented development speeds up programming by generating code based on tests/specs. Tests required will be the same or less specs as a normal developer writes.
https://github.com/Neur0plasticity/spec-dev
MSG me if interested
What is the relationship between webid and did（https://www.w3.org/TR/did-core/ ）？
@EurekaChen This channel is no longer in use. We are over at https://gitter.im/solid/specification . See also solid/identity-panel#1
I've been looking at the spec repos and I found this comment https://github.com/solid/solid-spec/issues/159#issuecomment-488292554
Node-Solid-Server also implements n3-patch which seems to be different from RDF patch, and relies on http://www.w3.org/ns/solid/terms#inserts, http://www.w3.org/ns/solid/terms#deletes, and http://www.w3.org/ns/solid/terms#where which seems pretty custom and undocumented?
Is it safe for a client to rely on that? Or is that just a
node-solid-server thing?
It’s a NSS thing at the moment. The plan is to a) implement N3 patch, b) send patches up the web socket instead of pub pings with no data; c) open up the client to peer to peer configurations like mesh configurations and CRDT and stuff. N3 patches anyone can parse and add more data to.
Would love it if someone did it but it is research level or someday pile at this stage on the roadmap.