con:PodServer and/or con:Server

[elf-pavlik]

In e85f558 @jeff-zucker fixed few occurences of con:Server to con:PodServer. While there was no con:Server, I actually would like to add it or rename con:PodServer to more general term.

Classes of products alerady provide a way to know what kind of server are we dealign with it, few examples:

• Storage
• OAuth Authorization
• OIDC Provider
• WebID Provider
• SAI Authorization Agent
• Notifications Subscription Server
• etc.

While all of them fall under very broad Server, I'm not sure if every one on it's own can be called PodServer. Maybe PodServer has to provide some minimum subset of above. In practice pod doesn't have normative definition, it is more of a marketing term which can mean different things to different people.

My preference would be to rename con:PodServer to just con:Server, later we could re-use spec:Server if it makes sense and fits SKOS+RDFS best practices. Otherwise we could add broader con:Server and hope that having both (Server and PodServer) will not cause too much of a confusion.

Also currently we only have con:PodServer, since there is no other prefixed con:FooServer, why do we even need to prefix it?

[jeff-zucker]

I actually would like to add it or rename con:PodServer to more general term.

I wasn't aware that Solid Efforts made any use of the SKOS concepts. Their main use is to structure the table of contents for the Resources Catalog and provide access to different subsets with the goal of making things maximally accessible to those with little or no knowledge of Solid. They are NOT intended to be a technical categorization of the resources, rather a social categorization based not on what the technical function is, but on how a person or organization would use it. "Server" is a technical term centered on the technical function of the thing. It says nothing at all about by whom or for what reason it would be used. "Pod Server" is a social function that describes a product that people can use for a specific purpose - providing or self-hosting pods.

In practice pod doesn't have normative definition, it is more of a marketing term which can mean different things to different people.

What you dismissively call marketing, I call onboarding. Every single piece of Solid onboarding material I am familiar with uses the term "Pod" -- the solidproject.org website, Tim's TAG Explainer for Solid, Jackson's tutorial on LDO. If there's a general move in the community to abandon this term we can abandon it at that point. At this point, however, it makes no sense for the catalog to take a different approach to onboarding than all the others.

Classes of products alerady provide a way to know what kind of server are we dealign with it,

Advanced users who need to know about those other kinds of servers can easily find the information both in the Resources Catalog and in Solid Efforts. The Resources Catalog is aimed at the same audience as the solidproject.org website. On that website, there is no mention of any of those other kinds of servers, it rightfully concentrates on the two primary ways that new users interact with Servers - to obtain a pod from a provider or to self-host. A first time self-hoster needs a list of Pod Servers - software that they can install to get a basic experience of Solid. Later they may want to add capabilities and explore other kinds of servers and server extensions. Therefore the Resources Catalog highlights Pod Server as a uniquely important piece of the ecosystem. It may be technically similar to the other kinds of servers but socially it is the only one that new users can be expected to interact with.

Also currently we only have con:PodServer, since there is no other prefixed con:FooServer, why do we even need to prefix it?

Because 1) "Server" defines a technical function with no indication of the social function whereas "PodServer" defines both and 2) in the future there may be con:IdentityServer and con:StorageServer instances which only provide one of the functions. We don't AFAIK have any of those now. These would refer to actual tangible products, not to abstract classes of products. Abstract classes do not have social functions, they are not resources that people can use. The SKOS concepts tree and table of contents for the Resources Catalog are about resources people can use and are categorized by those usages, not by technical function or abstract categories.

Solid Efforts does a great job of providing information for advanced users. I suggest you concentrate on it, rather than trying to impose ideas (which are indeed important for it) on the Resources Catalog which has a different audience and different teleological aim.

[elf-pavlik]

I wasn't aware that Solid Efforts made any use of the SKOS concepts.

I draw distinction between

• applications
• services - server side infrastructure
• shared libraries / modules

I used to have separate classes which all turned into Software while moving to a catalog data. Current SKOS mostly allows to preserve that distinction (with some squinting).

• *App - it would be nice not need to check all 4 variants
• PodServer - this issue mostly focuses on that since not all server, for example there is a Solid-OIDC extension for https://www.keycloak.org/ which I had in my original data
• SoftwareLibrary works for now

A first time self-hoster needs a list of Pod Servers - software that they can install to get a basic experience of Solid.

Currently SAI Authorization Agent appears there and if someone just deploys that they will not be able to use Solid. Similar once Keycloak appears there deploying just that will not be very useful.

---

I think this is related to what we were alerady discussing in #4 (comment)
Not all the viewers will use all the data, if there are some differences we should consider either including data needed by any viewer, and other viewers will ignore it, or having separate layers of data that is specific to specific viewers.

[jeff-zucker]

A first time self-hoster needs a list of Pod Servers - software that they can install to get a basic experience of Solid.

Currently SAI Authorization Agent appears there and if someone just deploys that they will not be able to use Solid. Similar once Keycloak appears there deploying just that will not be very useful.

Then there should be an additional concept for them, something like con:OtherServer. More specific information is carried in the COPs, I see no reason they need to be further differentiated in the SKOS.

I think this is related to what we were alerady discussing in #4 (comment) Not all the viewers will use all the data, if there are some differences we should consider either including data needed by any viewer, and other viewers will ignore it, or having separate layers of data that is specific to specific viewers.

So we would end up with multiple different data sets, all of which, by definition, would be incomplete from the point of view of any given viewer?

I don't see that the issue of how a PodServer is represented in any way necessitates multiple datasets.

[elf-pavlik]

Then there should be an additional concept for them, something like con:OtherServer

Since we are using SKOS can we have some broader and narrower? For example con:Server with some narrower concepts, also con:Application with the current bunch as narrower concepts. This way we could also remove con:OtherApp.

I'm not a SKOS expert but it seems to me cleaner to use a broader concept when there is no matching more specific one, instead creating OtherFoo concepts as a catchall.

[jeff-zucker]

Yes , we could have more than one SKOS scheme and an item could be in the current scheme as well as in a scheme more to your liking with e.g. con:ProductivityApp being narrower than both con:Product and con:Application. I am unclear why you need these broader categories. Aren't they already covered by COPs? Isn't a Notification Server a subclass of Server and aren't all apps subclasses or instances of the Client COP? If those relationships don't exist, can't you assert them?

it seems to me cleaner to use a broader concept when there is no matching more specific one,

The purpose of the SKOS concepts is to organize the Resources catalog table of contents and support easy retrieval of categorized data. How would one retrieve instances of those matching no specific case? Give me all applications that are not productivity apps or leisure apps or pod apps? How would it be listed in the Resource table of contents if not "Other Applications"? How would we be able enforce a SHACL constraint on all resources needing a con:subType if the only option is to leave the subType blank? How is constructing the "other applications" by round-about searching cleaner than simply marking them as other? Why is it important to have a listing of socially-relevant categories "clean" (by which you mean matching technical categorizations)?

[elf-pavlik]

How would it be listed in the Resource table of contents if not "Other Applications"?

If we remove con:OtherApp and do not introduce con:OtherServer, we can have following section of taxonomy:

• Application
  • PodApp
  • ProductivityApp
  • LeisureApp
  • FooApp
  • BarApp
• Server
  • PodServer
  • StorageServer
  • IdentityServer
  • FooServer
  • BarServer

If something doesn't fit unter any of the narrower categories, it can use the broader one. So to select your oher apps you could simply match on con:Application, since more specific one would have one of more specific sub types.

On the other hand, if I want to just show Apps/Servers/Libraries, I can't get that from the taxonomy and pretty much need to maintain those broader concepts externally. So if we add con:FooApp I need to add to that additional taxonomy con:FooApp skos:broader extracon:Application.

I think even for your viewer it can be benefitial to be able to list all the apps and not force the visitor to check all the subcategories if they don't want to start that specific.

[jeff-zucker]

If something doesn't fit unter any of the narrower categories, it can use the broader one. So to select your oher apps you could simply match on con:Application, since more specific one would have one of more specific sub types.

Okay, I think that can work.

On the other hand, if I want to just show Apps/Servers/Libraries, I can't get that from the taxonomy and pretty much need to maintain those broader concepts externally. So if we add con:FooApp I need to add to that additional taxonomy con:FooApp skos:broader extracon:Application.

Well either we have two taxonomies or we use my taxonomy based on social or your taxonomy based on tech. Maybe I could live with switching to a tech based taxonomy for apps/servers/libraries, let me think about it.

[elf-pavlik]

@jeff-zucker I believe you were working on it at some point, do you have any updates?

[elf-pavlik]

Taxonomy used by Solid Efforts will include suggested changes

• chore: update relation to Solid Efforts #83