Indication whether an Input is mandatory/optional to be provided

This can be done easily enough if the WG so decides.

Since the same input may be mandatory for one PS but optional for another, we can't make this a property of the input. We currently mandate that a Public Service must have at least one input, so that relationship is mandatory, but it doesn't mean that the input is mandatory.

Therefore, the only way to resolve this would be to have *two* relationships:

has required input

has optional input

This looks semantically nice but I worry whether it would be practical to implement? My proposal is just to stick with hasInput which implies that those inputs are required. Optional ones can be provided in descriptive text, i.e. "it helps us speed up your application if you provide X but it's not mandatory."

I would argue leaving the input totally optional. Above sounds like a compromise, describing things because they have to be described. I'd leave it to the common sense of the involved PO's taking up the mandatory input when relevant (omitting it when irrelevant).

In our case we're even thinking about automated payments of grants to citizens (for scholars). In that case there's totally no input required - just being in the right circumstances (having children of a certain age that attend school) and you get paid.

Concerning inputs to a service, we should be able to distinguish among different cases:

1. Service requests (e.g., the application for a school grant, a passport renewal, or a bus card)

2. Preconditions that need to hold in order for the service action to be executed (e.g., children of a certain age)

3. Events that may trigger the service action (e.g., sweeping the bus card while entering the bus)

4. Documents or other objects that are required to be processed by the service action (e.g., the old passport)

These are all examples that may be addressed by representing separately the service commitment and the service action. The service request is an input to the commitment, while the card sweeping is an input to the service action). The various kinds of input may described by ad-hoc relations.

I agree with Nicola that we need to disambiguate Input a bit. According to the suggested classification I feel like Inputs mainly fall in category 3 and 4, and that category 2 might be modelled as a Criterion, perhaps by referring to  https://joinup.ec.europa.eu/asset/criterion_evidence_cv/home. I'm less sure about category 1.

We didn't resolve this on the call of 24/5/16 so it need a bit more thought.

We have added the Criterion class (the criteria you need to fulfil in order to be eligible to use the service) and so that basic distinction that Nicola makes is being reflected. I'll change the cardinality of hasInput to optional. We're also changing the Input class to the CCCEV's Evidence class (which I am told has the same semantics so it's actually just a change of name). So we're still left with how to represent that a piece of Evidence is required and one that is optional. My favourite tool - Occam's Razor - says we just stick with hasInput as I really don't see how to cope with a piece of Evidence being mandatory for one service and optional for another without having the hasOptionalInput and hasMandatoryInput properties - that I think will make the vocab too complicated for many users.

More thought on this:

We could define two sub properties of hasInput (hasMandatoryInput and hasOptionalInput) and say in the documentation that the simplest solution is just to use hasInput but, where necessary, use the sub properties. 

The question is - is this actually necessary? Do we need to offer that level of complexity or are we better with just hasInput?

I have had no new feedback on this issue (also highlighted in a separate e-mail to the list) and so I am closing it with a resolution of 'do nothing' - i.e. we retain hasInput but make no distinction between mandatory and optional inputs.