– DRAFT –
DPVCG ftf day 2

<Bert> agenda for today (from yesterday's minutes)

Agenda for today:

* session1 9:30-11:00 - consent

* session: 11:15-12:45 - processing categories

----- After lunch: ----

* how to wrap up? discuss process for new terms and feedback

* timeline

** finish drafts (who, by when?)

** review (who, by when?)

** publish (when?)

** plan advertisement

** plan feedback cycles

* wrap up ISSUES (and ACTIONS) and discuss how we include them in the first draft, decide editors, etc.

<simonstey> list agenda

<simonstey> what's on the agenda?

https://‌docs.google.com/‌spreadsheets/‌d/‌13d1eRXZZBCw84vYGoCJeMU08rzkkzadDzxY3n2iOi8k/‌edit#gid=882529315

harsh: all properties in red still under discussion

harsh: biggest issue is the right to withdraw.
… ontology should provide a propery to state how to withdraw consent

mark: that's the mininmum, there;s no prior art for this.

axel: wouldn't it always be possible in writing to withdraw?

<rigo> watch out, consent withdrawl opens a can of worms as you can't just withdraw anytime

bud: law says it should be as easy as giving consent

<rigo> so the taxonomy should mention withdrawl and have the ability to point to something (URI)

mark: keep it minimal... we should keep it out of scope to fill the possible actions to withdraw consent in an own taxonomy for now, but we should have an attribute.

<harsh> I agree with what Rigo said, that's what we're trying to do in the spreadsheet currently.

mark: consent receipt would be ideal, but consent receipt has privacy information in it... some interaction with authentication, no one has been able to do consent receipts properly yet
… consent receipts are future work/innovation.

Axel: does consent need reconciliation with other legal bases?

Bud: fulfillment of conteact may be similar, but not really

<harsh> Contract can have expiry

<rigo> +1 to Bud, you need a legal reason to process without consent

<rigo> contract: if the main performances required by the contract are done (payment) the reason for processing expires, but this is Art. 6 (1) b

<rigo> we are discussing 6 (1)a and there I can't imagine a case where you still would need to process. Those personalization things can just be withdrawn

discussion on whether datasubject, controller, purpose, processing are part of consent, or consent is part of personal data handling....

axel: can be both, yes?
… so we need to modify the domain of hasDataSubject

hasDataController

hasPurpose

hasProcessing

hasPersonalData to the union of Consent and PesonalDataHandling?

bud: could we call it user rights?
… the consent might be the last point for the data subject to convey this information to the data controller

<rigo> to me, consent is part of personal data (SPECIAL annotation model) and it affects the properties of that data

bud: legally one has to state that the data subject has the right to withdraw
… otherwise it's not valid
… in the moment the processing starts, you have to provide the data subject rights

s

elmar: can you actually shift the responsibility of demonstrating consent

rigo: IF consent is a property of data and consent is removed, than the property is just deleted from the data (link/annotation destroyed)
… imo "withdrawl" is an algo, not a data property

bud: if you can process "pseudoanonym." then you need some form of ID for the data subject

axelpolleres: I don't understand why we have to explicitly put e.g. the right to rectify within the consent
… imo that doesnt belong to the consent but other legal basis

<rigo> +1 to axelpolleres

axelpolleres: consent can appear in different places

mark: the rights listing should go in the privacy policy

harsh: how do we capture the legal context under which consent was given?

<rigo> I think you should think things as "what can be done with the data" instead of thinking "how can I represent rights of GDPR". Because later, the algos will need data properties, not understand GDPR

mark: the privacy policy should have the rights notices

+1 to rigo

mark: collection method could be upgraded to "context"

collection method -> how consent was given

<rigo> does this matter?

<rigo> for audit it may matter, for the decision whether to process or not, it doesn't

Bert: do we agree that all the "right..." terms are not needed?

mark: it was part of the original vocab.

mark: in order to be compliant with ISO 29100, you have a lot of little requirements regarding presenting of notice
… the notice capture is not described by many groups so far

<rigo> bbl

axelpolleres: what's the difference between expiry/expiryCondition

axelpolleres: why do we have multiple expiry properties?

simonstey: why not combine it into just one property?

axelpolleres: how do we describe such a condition?

<harsh> To separate the expiry based on temporal and conditions , we have a common superproperty (hasExpiry) and specialisations for temporal (hasExpiryAtTime) and condition (hasExpiryCondition)

mark: in the UK there's always a 2year consent renewal period
… which they updated to 3 months

simonstey: do they have to adhere to the 3months?

mark: no.. but if they want to get certified, then yes

mark: there are a lot of controversies wrt. "on behalf"
… changed to "delegated"

axelpolleres: can we assume that it's the data subject if it's not there?

simonstey: OWA vs CWA

axelpolleres: is both withdrawal and provision be delegated?

harsh: withdrawal can be

bud: well a child cannot delegate
… if a child is turning 16 after the parents gave consent, it could withdraw it
… so you have to distinguish

harsh: authority captures why one was able to give consent on ones behalf

<harsh> e.g. John -- parent --> Jane

simonstey: one possible solution would be to add 2 additional properties one for withdrawal and one for provision that captures this

harsh: consent has to be given by one person only (according to a law professor I asked)

<harsh> in the context of this specific use-case we are covering

<harsh> Otherwise, legally, consent could be asked from multiple persons e.g. from both parents for a child

axelpolleres: next point, why do we need all those terms with "rights"

mark: you dont need to list them all

axelpolleres: if this is used for documenting, if I'm documenting the provision method it should also contain the information on how this was done

mark: the GDPR says explicitly the subject has to be informed
… which justifies a separate field

harsh: isnt this covered by provision method already?

axelpolleres: I thought this was only about "in text,.." etc.

[discussing consent notice, etc.]

axelpolleres: I put some description in the description
… The actual notice that the Data Subject received to consent to, either a text or link to a document, which should be usable to decide whether the form or consent was compliant to legislation, e.g. documenting how the user has been informed about rights and omplications (e.g. right to data portabilityright to recitffyright to erasureright to restrict processingright to objectrights regarding automated decision making or profilingprocessorsthird part[CUT]
… or outside-EEA transfers,profiling,automated decision-making,privacy-policy (mark))

bud: one has to document also e.g., whether checkboxes were prechecked or similar

axelpolleres: I think we could now argue for another full hour on how to structure such a notice..
… for now we could raise an issue saying consent notice could be further structured

Issue: Do we need to further structure consent notice?

<trackbot> Created ISSUE-16 - Do we need to further structure consent notice?. Please complete additional details at <https://‌www.w3.org/‌community/‌dpvcg/‌track/‌issues/‌16/‌edit>.

bud: I think we need a field indicating whether it's regular/explicit consent
… in special cases the GDPR requires explicit consent
… "not explicit" doesn't have a name in the GDPR

harsh: rigo explicitly said there's no "regular" consent

bud: we could have also only a boolean field indicating whether consent is explicit or not
… if explicit yes, then this indicates certain requirements
… article 22 2c -> explicit consent

bud: all parts of article 13/14 should be part of the notice, right?

mark: just because the GDPR doesn't call for a processor, doesn't mean we should not provide means for stating them

axelpolleres: we have now all properties of the personal data handling despite hasRecipient
… should we add this too?

bud: processor/3rdparty/... are all recipients

axelpolleres: the only thing we haven't discussed yet are bundles/groups

mark: in the GDPR special categories are listed explicitly

axelpolleres:
… can we now action someone to wrap this all up ?

axelpolleres: it's always the consent to personal data handling

harsh: well we have a property there called "storage"

axelpolleres: yeah.. but this is already covered by technical/organizational measures

mark: in the gdpr there are only a couple of mentions of "storage"
… where it's usually about storage period

[axel writing a description on gsheets]

axelpolleres: "We replicate all the properties except Legalbasis of personal data handling for consent, to declare what kinds of personal data handling are consented to"

mark: where's the field for internationaltransfer?

harsh: in the notice

mark: I don't think notice doesnt cover international transfer

bud: maybe you could add a remark saying that article 13 details all the things one has to notify about

issue-16

<trackbot> issue-16 -- Do we need to further structure consent notice? -- raised

<trackbot> https://‌www.w3.org/‌community/‌dpvcg/‌track/‌issues/‌16

axelpolleres: the green ones are for v1

BREAK for 15min

<axelpolleres> agreement: green ones in the spreadsheet are version 1.

session: 11:15-12:45 - processing categories

<harsh> Simon: I don't like just listing out actions for processing e.g. what's the difference between erase and destroy and delete

https://‌docs.google.com/‌document/‌d/‌1Z3Eb5rZjrdWcE5u5o0CYzA_LPyGaTqmg84ecGve_ZLA/‌edit

<harsh> Simon: We listed out categories such as scoring (in the document)

<harsh> yes

<harsh> while simon is speaking

<harsh> Simon: I would prefer a solution that allows describing processing

Simon: based on the (nature) of processing, it can assist in identifying whether the processing is high risk

Simon: Processing can involve new technologies/solutions, such as using ML for decisions.

Simon: We should identify the features or attributes of processing that distinguishes one from another

Elmar: controllers would want to use more generic descriptions

Axel: we should derive high level categories of processing, could even be keywords

bud: if your processing has high risk, you have to have a data impact assessment
… but that's towards the authority
… not towards the data subject
… so e.g. automateddecisionmaking for the purpose of giving a loan

bud: the data subject needs to know the purpose but not how it was done

axelpolleres: if I infer from your data, your sexual orientation based on your social media data/pictures for the purpose of advertism. or what not
… do they have to declare that they are inferring stuff?
… imagine you have this machine learning algo that infers sensitive information, where would I have to declare this

bud: about the processing, that are very few things one has to tell the data subject
… towards the regulator you have to do more (supervisor authority)
… they will ask those things when they audit you
… one has to demonstrate compliance with the law
… including measures to keep the residual risks low

MarkL: there's a missing way to explain the scope of processing

MarkL: these are like attributes for processing

axelpolleres: do I need to document which kind of software I use, database, ...?

bud: in my opinion this is outside of the scope

axelpolleres: processing=> what does a processor do to achieve its purpose?

axelpolleres: personal data=="click behaviour", purpose=="to sell you something"

harsh: starting from highlevel categories we could drill down

<harsh> Check definition of processing A4-2

<harsh> ‘processing’ means any operation or set of operations which is performed on personal data or on sets of personal data, whether or not by automated means, such as collection, recording, organisation, structuring, storage, adaptation or alteration, retrieval, consultation, use, disclosure by transmission, dissemination or otherwise making available, alignment or combination, restriction, erasure or destruction;

<harsh> We should at least cover all of these

harsh: collecting/storing/etc. (listed in the spreadsheet)

but those are operations rather than categories right?

also, maybe I'm fine if someone recording me on sundays but not any other day of the week

bud: iirc, there are about ~5 things one has to tell the data subject

<harsh> @simon yes, they are operations - I'm saying out categories should cover all those

bud: should sync with eva/rigo

ah yes

<MarkL> ** Risk Assessment ** * Evaluation or scoring * Automated-decision making with legal or similar significant effect [Bud: financial effects??] * Systematic monitoring * Matching or combining datasets * processing that involves new technological or organisational solutions * processing that “prevents data subjects from exercising a right or using a service or a contract” (Article 22 and recital 91)

<bud> https://‌ec.europa.eu/‌newsroom/‌article29/‌item-detail.cfm?item_id=611236

<bud> p..9

<MarkL> * Evaluation or scoring. * Automated decision-making with legal or similar significant effect. * Systematic monitoring. * Sensitive data or data of a highly personal nature. * Data processed on a large scale. * Matching or combining datasets. * Data concerning vulnerable data subjects. * Innovative use or applying new technological or organisational solutions. * Contexts Preventing data subjects from exercising a right or using a service or contract.

<MarkL> What does the ICO consider likely to result in high risk? The ICO is required by Article 35(4) to publish a list of processing operations that require a DPIA. This list complements and further specifies the criteria referred to in the European guidelines. Some of these operations require a DPIA automatically, and some only when they occur in combination with one of the other items, or any of the criteria in the European Guidelines referred to above:  1. Innov[CUT]

http://‌www.documentcloud.org/‌documents/‌4109562-20171013-wp248-rev01-Enpdf-Final-Guidelines-DPIA.html

page 9

<bud> https://‌gdpr-info.eu/‌art-30-gdpr/

<MarkL> https://‌ec.europa.eu/‌newsroom/‌article29/‌item-detail.cfm?item_id=611236

<axelpolleres> Axel: suggestion the 9 items there we should provide URIs for, just to be able to provide a handle for them.

bud: yes, for a supervissing authority this is interesting

<axelpolleres> purpose of our voabulary is essentially to provide not only machine-readeable means for compliance checking,but also a "rooster" for documenting and annoyating texctual policies, and checking whether all relevant parts are there.you

"An example of this is where a bank screens its customers against a credit reference database in order to decide whether to offer them a loan."

<harsh> There is another example at the bottom of page 11 that may help clarify this

<harsh> "Storage for archiving purpose of pseudonymised personal sensitive data concerning vulnerable data subjects of research projects or clinical trials"

<harsh> In this case, there is no associated "purpose", but the processing is associated with risk

<harsh> Or does "archiving" fall under legitimate interest of the clinic?

<harsh> Axel: do we leave the ones we have (6 from high-risk) for now?

action-66

<trackbot> action-66 -- Harshvardhan Pandit to Look into structuring processing categories, ramisa, bud, eva to help/review. -- due 2019-02-19 -- OPEN

<trackbot> https://‌www.w3.org/‌community/‌dpvcg/‌track/‌actions/‌66

monitoringDrivingBehaviour: hasProcessingType [

:typeProcessing :erasure;

:isAutomatedDecM true;

… : isSystematicMonitoring true ]

<Bert> From SPECIAL:

<Bert> Declaration(Class(svpr:Aggregate))

<Bert> Declaration(Class(svpr:Analyse))

<Bert> Declaration(Class(svpr:Anonymize))

<Bert> Declaration(Class(svpr:Collect))

<Bert> Declaration(Class(svpr:Copy))

<Bert> Declaration(Class(svpr:Derive))

<Bert> Declaration(Class(svpr:Move))

<Bert> Declaration(Class(svpr:Query))

<Bert> Declaration(Class(svpr:Transfer))

<axelpolleres> PROPOSED: as for processing we name operations as example (for instance SPECIAL, ODRL, bu do not define an own voabulary/taxonomy in this group.

<axelpolleres> seems to be agreement...

<axelpolleres> after lunch 20min max continue on wrapping up Processing, and then proceed the agenda.

<Bert> [Lunch, back in 1 hour]

Processing (continued)

<harsh> e.g Collect rdfs:subClassOf dpv:Processing, odrl:Collect .

<harsh> https://‌github.com/‌dpvcg/‌processing/‌blob/‌master/‌processing.ttl

<harsh> A4-2 ‘processing’ means any operation or set of operations which is performed on personal data or on sets of personal data, whether or not by automated means, such as collection, recording, organisation, structuring, storage, adaptation or alteration, retrieval, consultation, use, disclosure by transmission, dissemination or otherwise making available, alignment or combination, restriction, erasure or destruction;

Action: javier to put list of processing types into processing vocab on spreadsheet, merge with SPCIAL terms, add descriptions.

<trackbot> Created ACTION-88 - Put list of processing types into processing vocab on spreadsheet, merge with spcial terms, add descriptions. [on Javier D. Fernández - due 2019-04-12].

process for new terms and feedback

<axelpolleres> * process for new terms and feedback:

<axelpolleres> * Suggestions for reformulations or additions should be made in the form of pull requests on github via github's issues mechanism -->

<axelpolleres> * https://‌github.com/‌dpvcg

<axelpolleres> * labels: question, issue, proposal

<axelpolleres> * In regular calls we decide on proposals: "approve"/"decline"/"downgrade to issue"

<axelpolleres> * biweekly calls, after the first draft is published, we discuss whether we want to switch to monthly calls.

timeline

Action: Axel to finish base ontology by next call (within 2 weeks)

<trackbot> Created ACTION-89 - Finish base ontology by next call (within 2 weeks) [on Axel Polleres - due 2019-04-12].

<axelpolleres> PROPOSED: We use hash URIs in the namespaces.

<harsh> +1

<axelpolleres> PROPOSED: we use RDFS and OWL where needed

<axelpolleres> +1

<axelpolleres> +1 to both

<axelpolleres> reformulation of 2nd proposal:

<axelpolleres> PROPOSED: we define the vocabularies lary as an OWL ontology

<harsh> +1

<Ramisa> +1

Resolved: We use hash URIs in the namespaces.

Resolved: we define the vocabularies lary as an OWL ontology

Action: Axel to finish Technical ORganisational measures part in the spreadsheet by next call

<trackbot> Created ACTION-90 - Finish technical organisational measures part in the spreadsheet by next call [on Axel Polleres - due 2019-04-12].

<axelpolleres> ACTION-90 depends on Fajar providing a version of NACE we can use and on MArk's ACTION-87

<Bert> action-87?

<trackbot> action-87 -- Mark Lizar to Make a proposal alternatively use gics instead of nace. -- due 2019-04-11 -- OPEN

<trackbot> https://‌www.w3.org/‌community/‌dpvcg/‌track/‌actions/‌87

Action: Fajar to provide his conversion of NACE as RDFS/OWL

<trackbot> Created ACTION-91 - Provide his conversion of nace as rdfs/owl [on Fajar Ekaputra - due 2019-04-12].

Action: Elmar to finish Personal Data Categories and transfer what we agreed upon to the spreadsheet.

<trackbot> Created ACTION-92 - Finish personal data categories and transfer what we agreed upon to the spreadsheet. [on Elmar Kiesling - due 2019-04-12].

Action: Ramisa to drive discussion on Recipients, Data Controllers, Data Subjects forward

<trackbot> Created ACTION-93 - Drive discussion on recipients, data controllers, data subjects forward [on Roghaiyeh(Ramisa) Gachpaz Hamed - due 2019-04-12].

<axelpolleres> Action-92: change to elmar

<trackbot> Notes added to Action-92 Finish personal data categories and transfer what we agreed upon to the spreadsheet..

Action: Fajar to finish purposes.

<trackbot> Created ACTION-94 - Finish purposes. [on Fajar Ekaputra - due 2019-04-12].

Action: Harsh to complete Legal Basis

<trackbot> Created ACTION-95 - Complete legal basis [on Harshvardhan Pandit - due 2019-04-12].

Action: Harsh to consolidate consent part.

<trackbot> Created ACTION-96 - Consolidate consent part. [on Harshvardhan Pandit - due 2019-04-12].

Action: Axel define a process to get from spreadsheets to spec.

<trackbot> Created ACTION-97 - Define a process to get from spreadsheets to spec. [on Axel Polleres - due 2019-04-12].

Action: Axel to define process for feedback in spec document.

<trackbot> Created ACTION-98 - Define process for feedback in spec document. [on Axel Polleres - due 2019-04-12].

<axelpolleres> Next TelCo April 23rd, Bert chairs.

<axelpolleres> goal for next telco - all parts finished

<harsh> (ensure spreadsheet is complete)

<axelpolleres> Telco May 7th --> goal is to have a first full document for review, and including the ISSUES we have postponed or still rais on 23rd.

<MarkL> https://‌annualconference.eema.org

<axelpolleres> Telco: Internal reviews by 21st May

<axelpolleres> Mark: London https://‌annualconference.eema.org June 18+19 could be a good place to meet again.

<axelpolleres> Goal is to vote to publish on May 21st he first draft!

Action: Bert to look into where to publish our CG spec, and how to redirect from the namespace doc to the spec.

<trackbot> 'Bert' is an ambiguous username. Please try a different identifier, such as family name or username (e.g., bbos, bertv).

<axelpolleres> adversisement and feedback cycles to be discussed in the Telco on 21st May

<harsh> Action not assigned to Bert

<trackbot> Error finding 'not'. You can review and register nicknames at <https://‌www.w3.org/‌community/‌dpvcg/‌track/‌users>.

ISSUES

Action: bbos to look into where to publish our CG spec, and how to redirect from the namespace doc to the spec.

<trackbot> Created ACTION-99 - Look into where to publish our cg spec, and how to redirect from the namespace doc to the spec. [on Bert Bos - due 2019-04-12].

<axelpolleres> https://‌www.w3.org/‌community/‌dpvcg/‌track/‌issues/

<harsh> ISSUE- 2 to address in the report

<harsh> Axel: ISSUE-3 to be postponed

<harsh> Axel: ISSUE-3 Open, ISSUE-5 Postponed (correction)

<axelpolleres> close ISSUE-7 with answer "No"

<harsh> Axel: ISSUE-6 related to ACTION-93

<axelpolleres> close ISSUE-7

<trackbot> Closed ISSUE-7.

Issue: (ISSUE-8) As we agreed to use OWL for modelling, we use unionOf and intersectionOf from OWL.

<trackbot> Notes added to ISSUE-8 How do we describe unions and intersections of purposes, how doe we describe any vs some “sub”purpose.

<axelpolleres> close ISSUE-8

<trackbot> Closed ISSUE-8.

<Javier> ISSUE-9?

<trackbot> ISSUE-9 -- Where are categories of data controllers used, where are they useful? (cf. recital 98, 99, 100) -- raised

<trackbot> https://‌www.w3.org/‌community/‌dpvcg/‌track/‌issues/‌9

Issue: (ISSUE-9) relates to ACTION-93

<trackbot> Notes added to ISSUE-9 Where are categories of data controllers used, where are they useful? (cf. recital 98, 99, 100).

Issue: (ISSUE-10) related to ACTION-87 and ACTION-91

<trackbot> Notes added to ISSUE-10 Are there mappings to gics from other coding systems naics/nace/isic ....

Issue: (ISSUE-12) we won't get back to these actions.

<trackbot> Notes added to ISSUE-12 Shall we get back to action-6, action-19, action-27 (closed without news).

<axelpolleres> close ISSUE-12

<trackbot> Closed ISSUE-12.

Issue: (ISSUE-13) we use the namespace dpv for the ontology and subnamespaces only for mapping external terminologiessuch as eg. NACE,etc.

<trackbot> Notes added to ISSUE-13 Decide later whether we need sub-namespaces for different subtaxonomies.

<axelpolleres> close ISSUE-13

<trackbot> Closed ISSUE-13.

<harsh> https://‌www.w3.org/‌2006/‌07/‌SWD/‌SKOS/‌skos-and-owl/‌master.html

Issue: (ISSUE-14) we may refer to this link https://‌www.w3.org/‌2006/‌07/‌SWD/‌SKOS/‌skos-and-owl/‌master.html

<trackbot> Notes added to ISSUE-14 We may want to add a non-normative comment in the spec that/how the taxonomy can be used as skos..

Issue: (ISSUE-15) should be mentioned in section on PErsonal data categories.

<trackbot> Notes added to ISSUE-15 Personal data cateories collected might be collected in an approximate manner (e.g. age vs. age range), should we provide a mechanism in the vocabulary to distinguish this?.

Issue: (ISSUE-16) should be mentioned in the section about CONSENT (which as such will be a subsection of legal basis.

<trackbot> Notes added to ISSUE-16 Do we need to further structure consent notice?.

<Bert> https://‌www.w3.org/‌community/‌dpvcg/‌track/‌actions/‌open

Issue: Do we need further temporal annotations for the personal data handling class?

<trackbot> Error creating an ISSUE: could not connect to Tracker. Please mail <sysreq@w3.org> with details about what happened.

Issue: Do we need further temporal annotations for the personal data handling class?

<trackbot> Created ISSUE-18 - Do we need further temporal annotations for the personal data handling class?. Please complete additional details at <https://‌www.w3.org/‌community/‌dpvcg/‌track/‌issues/‌18/‌edit>.

Issue: (ISSUE-18) Do we need terms to document the time instant of specific personal data handling? the validity time of a certain policy? i.e. the temporal extent of a certain personal data handling instance.

<trackbot> Notes added to ISSUE-18 Do we need further temporal annotations for the personal data handling class?.

<axelpolleres> close ACTION-53

<trackbot> Closed ACTION-53.

Action: harsh to find URLs for GDPR articles.

<trackbot> Created ACTION-100 - Find urls for gdpr articles. [on Harshvardhan Pandit - due 2019-04-12].

<axelpolleres> ACTION-100: we will need thois for provenance of many of our terms.

<trackbot> Notes added to ACTION-100 Find urls for gdpr articles..

<axelpolleres> close ACTION-34

<trackbot> Closed ACTION-34.

<axelpolleres> close ACTION-33

<trackbot> Closed ACTION-33.

Action: JAvier to check after next Telco, which terms relate how to SPECIAL vocabularies (initially link them with rdfs:seeAlso

<trackbot> Created ACTION-101 - Check after next telco, which terms relate how to special vocabularies (initially link them with rdfs:seealso [on Javier D. Fernández - due 2019-04-12].

Action: Axel to copy definitions for StorageLocation and StorageDuration from SPECIAL for now.

<trackbot> Created ACTION-102 - Copy definitions for storagelocation and storageduration from special for now. [on Axel Polleres - due 2019-04-12].