Document current and upcoming spec coverage

[csarven]

This issue is not intended to bikeshed potential specs that's related to using Solid/WebID profiles.

It is to high level clarify the scope of the current spec ("Discovering Resources in a Solid Profile" as of this writing) and what may be intended to be covered in other specs.

[csarven]

I'll use an example that prompted this issue with respect to better aligning spec's (URL) shortname and title.

15 mentions shortnames like webid-profile under ED and TR space as well as whether the current title "Discovering Resources in a Solid Profile" is intended to cover only one aspect of Solid profiles (in which case webid-profile/discovery may be appropriate?) Simpler titles like "Solid Profile Discovery" (or even "Solid WebID Profile Discovery") could also work. It may be easier to hop off to "Solid Profile X" provided there is some need/documentation on X.

[jeff-zucker]

I do envision this as the first of three webid-profile specs. Unfortunately, they all involve discovery. What sets this one apart is that it deals only with discovery of infrastructure resources of the WebID owner, not the personal details of the WebID owner. So maybe webid-profile/resource-discovery, webid-profile/person-discovery, webid-profile/organization-discovery as names for the three subprojects?

[csarven]

Other considerations:

• whether the specs are considered to be discovery, data model, a bit of both, or something else.
• whether using a shortname like webid-profile and "Solid WebID Profile" as title suffices for different aspects of the material all in one document. (I think that may be a simple and flexible approach at this time.)

Are person-discovery , organization-discovery , x-discovery sounds like modules or profiles or shapes (or whatever perspective the spec should take).

If say webid-profile covers the core mechanisms, specific discovery/profiles can be published separately/independently. See for example, ODRL's Information Model: https://www.w3.org/TR/odrl-model/#profile .

This is within the scope of Variability in Specifications: https://github.com/solid/specification/issues/138 , https://www.w3.org/TR/spec-variability/#extensibility . WAC ( https://solid.github.io/web-access-control-spec/#extensions ) and Notifications Protocol ( https://solid.github.io/notifications/protocol#extensions ) took this approach and we can expect the Solid Protocol to have something similar, e.g., for auxiliary resources ( https://github.com/solid/specification/issues/270 ).

[jeff-zucker]

Hmm, discovery/data-model ... yes I see it as a bit of both, but oriented towards discovery i.e. an app's eye view of the profile.

I am not sure at this point the nature of the relationship with the other two specs might be. I would think, for one thing, that those documents will be aimed at the owner rather than the app developer i.e., how can I as a person or organization, use the profile in ways I want. So possibly having a different audience as well as a different content.

I would be fine with this current document being an umbrella document for the others, i.e. take your suggestion of using this repo and the name "Solid WebID Profile" as long as we don't have to get too specific about what the other documents will be. My main interest in dividing things up was wanting to get the discovery part released without having to complete the other parts.

[csarven]

This issue is just to see how the current work can be generally classified, divided or extended. We should not wait for the other parts - whatever they are concretely - to be ready in order to get what's on hand out. The current spec doesn't need to make any promises either. The document can be extended if and when necessary or picked up in other specs.

[VirginiaBalseiro]

Would this be partially covered by https://github.com/solid/webid-profile#goals?

[VirginiaBalseiro]

https://github.com/solid/webid-profile#content-addressed needs a bit of work/clarification IMO