[NEW]: Add Maintenance as a `dpv:Purpose`
Specs
DPV
New Concept(s)
Term: Maintenance Label: Maintenance Definition: Purposes associated with maintaining a service or product Parent term: dpv:ServiceProvision Source: (url or reference) Usage note: For example, I want to define a policy that states 'Alice allows technicians from SmartHomeCo to access her IoT devices for maintenance purposes during working hours if she consents' and be able to express maintenance as its purpose.
Thanks Beatriz. Agree with the concept, though I think it should be ServiceMaintainance to align with the existing ServiceXYZ phrasing. Also I think @TyttiKatariina will be proposing concepts related to service management, access, and monitoring, so we will include this concept when discussing those. The definition should be more descriptive e.g. we can style is after Maintenance -- Wikipedia.
@besteves4 as we're finalising v2.2, should this term be prioritised now (as in you need it in your work) or should we discuss it with other ServiceXYZ terms and add it in v2.3 in December?
I'm already using it in a paper, but I can do something like ex:ServiceMaintainance rdfs:subClassOf dpv:ServiceProvision if people prefer to leave it to v2.3
Thanks, then let's add it in v2.3 alongside other terms. Also gives us time to refine what is meant by "maintenance".
This concept came up in discussions on how to model a policy for "Alice allows SmartHomeCo technicians to access her IoT devices for maintenance purposes", e.g.,
<http://example.org/alice-smarthome> a odrl:Set ;
odrl:uid ex:alice-smarthome ;
odrl:permission [
odrl:action dpv-odrl:Access ;
odrl:target ex:alice-iot-devices ;
odrl:assigner ex:alice ;
odrl:assignee ex:smarthomeco-technicians ;
odrl:constraint [
odrl:leftOperand dpv-odrl:Purpose ;
odrl:operator odrl:isA ;
odrl:rightOperand ex:ServiceMaintenance ] .
So something like "Purposes associated with maintaining a service, such as repairing, updating or replacing part of or the whole service to maintain its expected functionality" as a definition?
For the DPIA required conditions collected from the GDPR, EDPB Guidelines and Data Protection Authorities, two ServiceXYZ concepts arise.
ServiceAccessDetermination needed to represent the purposes associated with the determination of whether specific conditions or criteria are met for accessing, using, or gaining access to a service under parent dpv:ServiceProvision
ServiceMonitoring needed to represent the monitoring of services(s) to understand their performance and utilisation with a view to inform their management under the parent dpv:ServiceManagement
If relevant for this discussion, there are also two risks arising from Service Management/ maintenance that are mentioned in the DPIA requirements:
ServiceAccessDenied needed to represent where an individual or an organisation is prevented from accessing a particular service under the parent risk:ServiceRelatedConsequence
ServiceAccessAllowed needed to represent where an individual or an organisation is permitted to use or access a service under the parent risk:ServiceRelatedConsequence
Thanks @TyttiKatariina I think ServiceAccessDetermination and ServiceMonitoring should go in purposes taxonomy -- we should see what is the hierarchy between these and ServiceManagement (seems like it is the parent concept of all these?). The ServiceAccessDenied and ServiceAccessAllowed would be in RISK extension as consequences, as they will be helpful in impact assessments (which is what I think your goal here).
Consolidating the proposal concepts:
`dpv:ServiceManagement`
|-- `dpv:ServiceAccessDetermination`
|-- `dpv:ServiceMaintainence`
|-- `dpv:ServiceMonitoring`
|-- `dpv:ServiceUsageAnalytics` (existing -- change parent)
|-- `dpv:ServiceProvision` (existing)
|-- `dpv:ServiceOptimisation` (existing -- change parent)
|-- `dpv:ServicePersonalisation` (existing -- change parent)
Discussion needed on whether some of these concepts should be subclasses of ServiceProvision or independent of it i.e. are they necessary when providing a service? -- I think no because the legal basis for provision is contract whereas the separated ones may be based on legitimate interest; and also whether these can exist independently of service provision.