Provide vocab/terms for Solid Pod related entities and functionalities

[coolharsh55]

Hi. Currently the vocabulary does not provide sufficient concepts to represent information related to Pod functionalities. For example, Who developed/provided the App? Who is the Infrastructure provider for Solid? These terms should be provided through the solid vocabs to enable representing use-cases with correct granularity. This vocabulary should also establish the terms for entities that may take different roles in relation to Pods - e.g. who provided the server, who provided the software, etc. Such clarity in terms regarding entities, roles, and functionalities will help transparency in the Pod provisioning and use, maintaining records, and most importantly - legal tasks related to ensuring appropriate responsibilities and agreements are established.

For example, the following are based on existing standard for cloud terminology ISO/IEC 22123-1:2021 Information technology — Cloud computing — Part 1: Vocabulary where Solid is interpreted as a Data Storage technology (Solid and Pod are prefixed for informative purposes):

• Solid Pod is a cloud service of type data storage as a service (DSaaS) - which itself can be IaaS, PaaS, or SaaS.
• Pod Provider is a cloud service provider that makes services available
  • Pod Infrastructure Provider - provides the infra e.g. server
  • Pod Platform Provider - provides the platform on which Solid must be installed
  • Pod Software Provider - provides the software for Solid e.g. ESS
• Pod Customer is a cloud service customer that is in the business relationship of being provided the Solid Pod (can be a person or an organisation)
• Pod User is a cloud service user that uses Solid Pod (can be a person or a device or an application) associated with a Solid Pod Customer
  • Distinguish between Pod User as a Person and Pod App, this is for the Person, and we create separate concept for App
• Pod Partner is a cloud service partner that provides support or auxiliary activities for Solid Pods
• Pod Auditor is a cloud auditor that can audit Pods
• Pod Broker is a cloud service broker that negotiates between providers and customers
• Pod Developer is a cloud service developer
• Pod Capability Type is cloud capability type
  • Application/Software - Pod can provision and use the Provider's Applications
  • Infrastructure - Pod can provision and use the Provider's Infrastructure (e.g. processing, storage, networking)
  • Platform - Pod can deploy, manage, and run Customer's apps with Provider supported environments
  • Compute - Pod can use Provider to provision and use processing resources
  • Communication - Pod can use Provider for communication
  • Data Storage - Pod can use Providers provision and use of data storage
  • Network - Pod can use Providers networking capabilities
• Pod Agreement - agreement between Provider and Customer regarding the Pod
• Solid App - an application implementing the Solid Specs
• App Provider is the provider of a Solid App
• App User - user of the app
• App Developer - developer of the app
• App Agreement - agreement between App and User
• Interoperability Types
  • service - Pod Apps/Services can communicate with each other
  • transport - Pod Apps use common communication infrastructure
  • synctactic - Apps use interoperable format exchanges
  • semantic - Apps use interoperable data model
  • behavioral - Apps achieve expected outcome from interoperability
  • policy - portability is achieved while complying with policies
• Portability Types
  • data - can be taken out of the pod
  • pod data - can be moved from pod to pod
  • data synctactic - is provided with data formats
  • data semantic - is provided with data model
  • data policy - portability while complying with policies
  • application - can be moved pod to pod
  • application synctactic - application data is provided with formats
  • application instruction - application instructions are moved
  • application metadata - application metadata is moved
  • application behavior - application behavior is ported/same
  • application policy - application is moved while complying with policies

[ThisIsMissEm]

For:

Who developed/provided the App?

I'd recommend taking a look at Client Identifiers, which are JSON-LD documents that describes an application

[coolharsh55]

I have written up an article titled "Making Sense of Solid for Data Governance and GDPR" https://osf.io/m29hn/ that provides more context and depth for the above as well as an analyses of GDPR compliance and how existing issues can also be applicable for Solid. There are some specific ideas for improving things (Section 8) -- which relate to the above, as well as expands on the discussions in solid/data-interoperability-panel/issues/282 (separation of Agents) and solid/authorization-panel/issues/46 (trusting an app).

[csarven]

I have a couple brief comments:

Generally I like this. And, we should refer to existing stuff out there.

Where applicable or available, terminology should be based on technical terms from specifications for example. There is room for layperson terminology for things like "pod", but if we are essentially talking about a "service" or a "server" or a "storage", those would be better than "pod" since the latter is not well-defined and not all "pods" have equivalent functionality.

Regarding "Interoperability Types" - I think that's generally covered by Classes of Products in specifications, e.g., https://solidproject.org/TR/2024/protocol-20240512#classes-of-products , https://solidproject.org/TR/2024/notifications-protocol-20240512#classes-of-products , so when a class of product needs to be references, that should point where they are defined in specifications where available instead of the vocab. That said, http://www.w3.org/ns/spec#ClassesOfProducts is a Concept Scheme with some top concepts based on https://www.w3.org/TR/spec-variability/#cop . Specs can specialise them or come up with their own.