Look into compatibility with current practices

[woutermont]

As raised in https://github.com/solid/webid-profile/issues/68, and also discussed in https://github.com/solid/webid-profile/issues/65#issuecomment-1288210861, the WebID-Profile proposal i.m.o. conflates the normative and the descriptive, resulting in a number of problems with their document. The main defense of the proposal, voiced by @jeff-zucker, is that it wants to keep compatibility with the current way of doing things; something, he rightfully says, the SAI spec has up till now failed to do.

With this issue, I would therefore like to bring this lack of compatibility to he attention of the contributors, and ask that this is taken more into concern. On way to do so would be to split both SAI and WebID-Profile into separate mixed (sub)specs, and bundle our forces there, tackling one orthogonal problem after the other (as suggested in https://github.com/solid/data-interoperability-panel/issues/284).

[justinwb]

The main defense of the proposal, voiced by @jeff-zucker, is that it wants to keep compatibility with the current way of doing things; something, he rightfully says, the SAI spec has up till now failed to do.

To characterize it as "failing" would be inaccurate. We deliberately did not follow the legacy mechanisms used because they failed to meet the stated problems and goals for security and interoperability. If the legacy mechanisms did so, we wouldn't have had to undertaken all of these efforts in the first place.

With this issue, I would therefore like to bring this lack of compatibility to he attention of the contributors, and ask that this is taken more into concern.

A good start would be for webid-profile to include people using SAI as part of their definition of current. If the stated goal was truly to document current use, I don't see how SAI isn't included in that (given that we have mutliple open-source and commercial implementations and real-world use).

Essentially, adding support for SAI to webid-profile would be a simple matter of including the following to the webid document:

  interop:hasRegistrySet alice:registries ;
  interop:hasAuthorizationAgent alice-jarvis: ;
  interop:hasAccessInbox alice-inbox:access .

People can then choose which mechanism(s) they want to use.

[woutermont]

We deliberately did not follow the legacy mechanisms used because they failed to meet the stated problems and goals for security and interoperability.

Of ccourse I am all in favor of solving the issues that the legacy mechanisms have. I do believe, however, that this can be done while keeping support for those implementations, e.g. as anonymous, insecure, untrustable clients.

A good start would be for webid-profile to include people using SAI as part of their definition of current. If the stated goal was truly to document current use, I don't see how SAI isn't included in that (given that we have multiple open-source and commercial implementations and real-world use).

Which is something I repeatedly hammered on with @jeff-zucker, @VirginiaBalseiro, @ThisIsMissEm and @timea-solid.

Essentially, adding support for SAI to webid-profile would be a simple matter of including [three triples] to the webid document [...] People can then choose which mechanism(s) they want to use.

The main reason why I keep raising this both here and at WebID-Profile and TypeIndexes is precisely that the word 'choose' here is a very restrictive one: people can only make an uninformed decision between either fully using the old mechanisms and not using any SAI app, or the other way around.

[ThisIsMissEm]

given that we have mutliple open-source and commercial implementations and real-world use

@justinwb would you be able to list which existed when the webid-profiles spec started ~10 months ago? I've only become aware of implementations of SAI in the last two months or so; maybe do a post on the Forums or a talk a Solid World about them? (it's entirely possible I've missed this)

[ThisIsMissEm]

As for:

A good start would be for webid-profile to include people using SAI as part of their definition of current. If the stated goal was truly to document current use, I don't see how SAI isn't included in that (given that we have multiple open-source and commercial implementations and real-world use).

@justinwb @woutermont I don't think supporting SAI is just adding those predicates to the WebID Profile Document or Solid Profile Document, as those predicates require the SAI authorization server protocol to be supported (to resolve the mapping between WebID + Client ID, via the access token, and the destination dataset for that application). At least, that's my understanding of how this is meant to work?

But also webid-profiles doesn't limit the upper bounds of what you can have in either document, it just says recommended places for certain content (authorization + identity in WebID Profile Document, metadata / descriptive data in Solid Profile Document)

[woutermont]

No, supporting SAI is not that simple (it also needs clientside implementation to work with those triples).

What @justinwb says is what I've been repeating the past weeks: SAI is here, SAI is being used, so a "current best practices" document should take it into account. But let's not rehash that entire discussion.

[elf-pavlik]

I think good candidate would be #254 where we were talking about concept of PublicAgentRegistration. This could be aligned with how Type Indexes currently work since there is no concern of privacy and the issue with leaking information per-authorization. Of course I think we would want to keep taking advantage of shape trees.

[woutermont]

Yes, big fan of that idea, @elf-pavlik!

Not sure about the trees though. I'm more in favour of leaving out the dependence on trees, and only use them as ONE way to describe data form.

[ThisIsMissEm]

I think good candidate would be #254 where we were talking about concept of PublicAgentRegistration. This could be aligned with how Type Indexes currently work since there is no concern of privacy and the issue with leaking information per-authorization. Of course I think we would want to keep taking advantage of shape trees.

Maybe there's something more like ShapeTrees that could make sense to supersede TypeIndexes? My gut feeling is that generally you want to describe a shape of information being written, not just the RDF Class / type. Maybe a "ShapeIndexes" or something?

Admittedly I'm not fully versed on ShapeTrees yet, but it does seem like you'd want to be able to query a pod for data that have a specific shape, and indexing that might be a good stepping stone?

[ThisIsMissEm]

No, supporting SAI is not that simple (it also needs clientside implementation to work with those triples).

What @justinwb says is what I've been repeating the past weeks: SAI is here, SAI is being used, so a "current best practices" document should take it into account. But let's not rehash that entire discussion.

Ah, right, okay! I think the confusion is that folks haven't learned of / been able to play around yet with SAI, so it's not as accessible to developers & spec writers as the other existing "current practices"

[woutermont]

True, the SAI spec is rather a hard read (which it need not be): it is too heavily loaded with explanatory tables, schema's and examples to really get the (rather small) gist of it.

[woutermont]

[@ThisIsMissEm] Maybe there's something more like ShapeTrees that could make sense to supersede TypeIndexes? [...] Maybe a "ShapeIndexes" or something? [...] [I]t does seem like you'd want to be able to query a pod for data that have a specific shape, and indexing that might be a good stepping stone?

Perfect! Here you touch the core of [A] why SAI discovery is more usefull than just TypeIndexes, and [B] why SAI itself should lose its dependency on ShapeTrees.

What we need, in pure abstraction, is a way to declare the form of the data you need to access.

RDF Types do that, be it rather vague. ShapeTrees do that, but depend on complex document hierarchies. ShaCL or ShEx shapes do that. Triple Pattern Fragments do that. A SPARQL query does that. And each of them has their advantages and disadvantages.

Based on this multitude, a generic discovery mechanism should be able to tell you [1] where data can be found, and [2] what its form is, in any of the above (and more) languages. In essence, such a mechanism thus describes the available interfaces (APIs) to the dataset: which endpoint can deliver/process what kind of information.