w3c
Specifying "Cloud Computing" in DPV-TECH
During discussions, we avoided defining the term 'cloud'. However, the term is important as increasingly standards, laws, guidelines, etc. have started to directly refer to 'cloud computing' and 'cloud technology' without themselves defining what exactly they mean, and relying on the common use of the term. Reflecting this, DPV-TECH should provide 'cloud' as a means of specifying the infrastructure of the service.
This can be done by creating the concept TechnologyInfrastructure and specifying OnPremiseInfrastructure and CloudInfrastructure as two types. This is distinct from TechnologyUsageLocation since a cloud technology can also be utilised locally, e.g. accessing a service deployed on cloud from local machines. The separation of Infrastructure as a concept from Location of Use as a concept reflects this.
Hi. Thanks. Any suggestions for concepts and modelling? Last I remember, the issue was that "cloud" is a loosely defined term with several possible combinations, e.g. on-demand, storage vs processing, distribution, availability, distinctions between IaaS / PaaS / SaaS. It also was not clear how to model relation to 'local' processes, e.g. a locally executed application that utlises 'cloud' data storage.
I will try to prepare something and share it later. For example for IaaS, Paas.., I would put it under ServiceModel. Also, we should include the new emerging paradigm which is getting quite popular, the hybrid cloud paradigm. In my view adding the Edge computing would also be the good.
Thanks for the quick reply and the nice diagram : )
- The
ServiceModelconcepts could be the provided instead asProvisionMethodsince it describes how those technologies are provided ? - So, can we say 'Cloud Computing' is a category of how technologies are provided, which means we'd need to add
Platform,Software, andInfrastructuretoProvisionMethod(the concept Service exists)? And then extend theServiceconcept to representIaaS,SaaS, andPaaS? - Types of Cloud as Public, Private, Hybrid - are well defined. Is "Community" a common cloud categorisation?
- Can the modes of access be generalised as a separate concept to instead refer to whether that technology is public facing or is private or hybrid, e.g. as
isAccessibleBywithPrivate,Publicreferring to categorisation of actors. This can enable extending to specify additional specific things such asDevelopmentTeamas a specific type of private access.
To summarise:
TechnologyProvisionMethod
|-- Product
|-- Infrastructure
|-- Platform
|-- Software
|-- CloudTechnology
|-- Service
|---- SaaS (subclassOf Software + Service + Cloud)
|---- IaaS (subclassOf Infrastructure + Service + Cloud)
|---- PaaS (subclassOf Platform + Service + Cloud)
`isAccessibleBy` relation with range TechnologyActor
TechnologyActor
|-- PublicActor (e.g. authorised public user)
|-- PrivateActor (e.g. authorised personnel)
|-- Existing concepts can be combined, e.g. Developer + PublicActor, or User + PrivateActor
The ServiceModel concepts could be the provided instead as ProvisionMethod since it describes how those technologies are provided ?
I would not do say it as a ProvisionMethod. The reason is people might get confused because the term provisioning is used for resource allocation and is independent of IaaS or PaaS.
So, can we say 'Cloud Computing' is a category of how technologies are provided, which means we'd need to add Platform, Software, and Infrastructure to ProvisionMethod (the concept Service exists)? And then extend the Service concept to represent IaaS, SaaS, and PaaS?
We can categorise Cloud Computing as subtype of technology.
Types of Cloud as Public, Private, Hybrid - are well defined. Is "Community" a common cloud categorisation? Yes. A community cloud is shared among two or more organisations that have similar cloud requirements."
Can the modes of access be generalised as a separate concept to instead refer to whether that technology is public facing or is private or hybrid, e.g. as isAccessibleBy with Private, Public referring to categorisation of actors. This can enable extending to specify additional specific things such as DevelopmentTeam as a specific type of private access. No, in my view.
Okay. The intention of provision method is to specify that a technology is developed, used, or reused from someone else in the specified form. This allows it to separate the method by which that technology is obtained and used (re. provisioned) from the purpose of the technology itself, such as Data Storage, Security, etc.
Defining Cloud as a subtype of Technology is fine, but then the further subtypes IaaS, PaaS, SaaS have both sides (e.g. Software and Service) as being provision methods. So I think its better to group these alongside services, apps, etc. Note that provision is actor-agnostic i.e. it can be provisioned by the current entity or external entity. Again, the intention is to express the purpose of technology through its subtype, e.g. data, security, operations - and then specify how this is being implemented / deployed / provisioned - service, app, cloud (IaaS, PaaS, SaaS). This also allows asking who provided this technology for a distinct set of terms (i.e. provision methods).
You specified that public / private cloud cannot be indicated as access modes. Do you have any suggestions on how to represent these? Or how to indicate non-cloud technology in a similar manner i.e. private or public? Because it would be better to be consistent for the meaning of terms private and public across any technology rather than defining them as subtypes of only cloud.
Perhaps this discussion can benefit from taking some examples and charting the resulting triples to see what seems better...
Maybe we should first see if there already exist some ontology that we can reuse? I found one -- https://ieeexplore.ieee.org/abstract/document/4738443
Good suggestion, thanks Tek. The paper has a lightweight ontology, and I think some terms don't make a good fit. Such as "Data Storage as a Service" -- DaaS would still be a part of IaaS/PaaS/SaaS depending on how it is being provided. Same for communication (which is a type of infrastructure). These would be a hierarchy of SaaS.
Wikipedia has a good collection of these terms - https://en.wikipedia.org/wiki/Cloud_computing see the index box at the bottom of the page. My impression is that if we reflect this list (to start with), then "Cloud" would be a prefix to create additional variations for each category of existing concepts of infrastructure, platform, application (i.e. software), and service. This would provide a simple template for any future categorisation of "provision method" or category of technology to be specified as cloud by combinations. E.g. Security as (cloud) Infrastructure or Management as (cloud) Software. And because we express these as
As usage grows, new concepts comes in to use, the extension of this taxonomy would be simple and consistent also for non-cloud technology. I will try to model the examples of cloud things in that list on Wikipedia using this when I get back to the office next week. It may help to see if this idea makes sense or should be discarded.
For data protection, we also need to have a link between the could concept and the geolocation concept. Because some of the more sensitive processing e.g. requires to be in EU boundaries only. This is partly what Gaia-X is about. We should integrate that concept with "SLA" or an open end to concepts like Gaia-X.
Hi. Thanks, that's one of the difficult bits of how to represent 'cloud'. In DPV, we have the GeographicCoverage which can specify the 'extent' of cloud, in addition to indicating specific locations using hasLocation. This should work to express the 'boundary' in addition to specific server locations.
Updates: Found ISO/IEC 17788:2014 Information technology — Cloud computing — Overview and vocabulary and 35.210 Cloud computing series that provide a vocabulary for cloud computing. So it might be better to utilise these existing well defined terms.
For example, ISO/IEC 17788:2014 mentions X as a Service for the following:
- Compute as a Service
- Communications as a Service
- Data Storage as a Service
- Infrastructure as a Service
- Network as a Service
- Platform as a Service
- Software as a Service
From ISO/IEC 22123-1:2021
- cloud computing
- resources: servers, operating systems, networks, software, applications, and storage equipment
- cloud service
- cloud deployment model
- community cloud
- hybrid cloud
- private cloud
- public cloud
- cloud service customer
- cloud service provider
- cloud service user: natural person, device, application
- cloud service partner
- cloud auditor
- cloud service broker
- secondary cloud service provider
- device platform cloud service: app marketplace
- cloud service developer
- tenant
- on-demand self-service
- resource pooling
- cloud capabilities type: application, infrastructure (processing, storage, networking), platform
- cloud service category
- communications as a service
- compute as a service
- data storage as a service
- infrastructure as a service
- network as a service
- platform as a service
- software as a service
- cloud interoperability
- transport interoperability
- syntactic interoperability
- semantic data interoperability
- behavioural interoperability
- policy interoperability
- service level agreement
- cloud service product
- product catalogue
- service catalogue
- cloud service level agreement
- cloud service level objective
- cloud service agreement
- failure notification policy
- cloud application portability
- data portability
- cloud data portability
- data syntactic portability
- data semantic portability
- data policy portability
- application portability
- application syntactic portability
- application instruction portability
- application metadata portability
- application behaviour portability
- application policy portability
- cloud service customer data
- cloud service derived data
- cloud service provider data
- individual data
- organizational data
- organizational protected data
- public domain data
- inter-cloud computing
- secure multi-tenancy
- primary cloud service provider
- peer cloud service
- virtual machine
- virtual machine monitor / hypervisor
- container
- container image
- architecture
- application cloud service
- device
- device platform
- application marketplace
- cloud native application
- device platform provider
- device platform cloud service provider
@coolharsh55 This looks good. I saw in some EU documents about cloud, they're using the term "transfer location", maybe we can also make use of it to make explicit about the data transfer operations. But again, there's already location information, so the question might also arise if we need this?
I will share the doc soon.
Hi. Thanks. For transfer, the main dpv spec already covers data storage/transfer and other processing operations, plus their locations. So it should be used for specifying cloud servers that are spread across locations, and then we can see from there if there's a need to express concepts directly for cross-border transfers or if this is sufficient.
(from Georg) https://cloud.google.com/free/docs/aws-azure-gcp-service-comparison shows different cloud technology providers and how they are compared using specific concepts.
Discussed with Delaram and we propose the following resolution to the current 'deadlock' between tech concepts having a huge overlap with DPV concepts (e.g. Tech/Org measures) as well as the modelling of AI concepts
- the tech/org measures from DPV shouldn't be duplicated in TECH to create categories of different technologies; all categories should be added to DPV's TOM taxonomy
- TECH extension only provides information such as provider (actors), or provision method (e.g. cloud), network connectivity (e.g. bluetooth), environment (e.g. smartphone app) etc.
- AI extension will be a completely separate and detached extension from TECH that will provide a taxonomy of techniques, capabilities, etc. for AI
Continuing discussion from https://w3id.org/dpv/meetings/meeting-2024-05-15