Extending the Processing Time property of a Public Service

An alternative approach would be to use the OWL Time Ontology's method of describing a duration. See https://www.w3.org/TR/owl-time/#duration (This doc is now under development at W3C to make it a formal standard but basics like duration descriptions are not expected to change - they're too well established and widely used.)

Perhaps 'Duration' or 'Time period' or 'Legal period' terms , are a more accurate approach for Time property and it would apply to services  without "processing step"; i. e. services that only provides information but with a 'life period' for the information provided

As well as OWL time, other alternatives include:

• ISO8601 durations, e.g. P1M for one month. This works if we want to give a duration, but not things like opening hours.
• schema.org's opening hours property/value syntax, e.g. Tu,Th 16:00-20:00, meaning Tuesdays and Thursdays 4-8pm.

As values for processing time, the ISO-8061 method looks appropriate. For opening hours, the schema.org approach seems a better fit. Therefore, that's the proposal:

• Use ISO-8601 periods for processing time (schema:processingTime requires this)
• Use schema.org's openingHours and its syntax for values.

But does this cover the motivations for the properties created for the CPSV-AP-IT?

The previous definition of the processing Time property said: "This property represents an indication of time needed for executing a Public Service. This can be a time range, average time, exact time for execution or any other indication of time" - is that flexibility desirable?

This is more or less a duplicate issue of https://joinup.ec.europa.eu/asset/cpsv-ap/issue/more-detail-period-time

The model circulated by e-mail on 12/5/16 does this.

I made a mistake, this is about Processing Time, not Period of Time in which the service is available. Inspired almost entirely by the Italian experience, I propose the following:

The Processing Time Class

This class represents the time it takes to operate a Public Service for a given client. This can be a time range, an average time, an exact time for execution or any other indication of time. The actual information is provided by a combination of three properties in addition to the usual identifier. They indicate the number and unit of time (e.g. 3 days) plus an indication whether this is an average time, an exact time or a maximum time.

Identifier [1..1]

This property represents a formally-issued Identifier for the Processing Time.

Measurement Unit [1..1]

This property indicates the unit of time using a controlled list of values: Minutes, Hours, Days, Weeks, Months, Years.

Quantitative Vale [1..1]

This property provides the number of units.

Type [1..1]

The type property of the Processing Time class uses a controlled vocabulary to indicate whether the indicated period is: exact, minimum, maximum or average.

Dear all

Given the broad use of microdata and schema.org I suspect that in practice http://schema.org/Duration, and thus ISO8601 notation for duration, is often used and that this usage will only increase, e.g. on government websites.

Can such notation still be used in this proposal? Maybe I am missing some cases which cannot be covered using 'Duration', but I can't think of any right now.

We can certainly use ISO8601 Durations - which I'd favour *except* that we need, I think, a way of expressing whether the processing time is a minimum, maximum or average.

In fact, schema.org includes a class of ServiceChannel that has a property of processingTime for which the definition is 'Estimated processing time for the service using this channel.' If that's sufficient for our needs then I agree that the simplest thing would be just to use that. If we can address that 'if' then I'm all for it.

Resolved on 24/5/16 to just use estimated processing time. Local implementations can add further details if required.

Coming back to this issue, it seems that there is no requirement to indicate whether a period is minimum, maximum or typical. Therefore the simple solution suggested by Thimo and used by schema.org seems the most appropriate. https://en.wikipedia.org/wiki/ISO_8601#Durations explains the syntax clearly.