Variable Duration Support

[peter-dolkens]

Open endpoint for QA:

https://api.runtogether.co.uk/odi/public/courses

-- AND / OR --

Sample JSON:

"subEvent": [
  {
    "type": "ScheduledSession",
    "url": "https://groups.runtogether.co.uk/RunningFree/Runs/Summary/ea313abf-4aad-4341-a827-da059c3ee00f",
    "startDate": "2018-10-01T17:00:00+01:00",
    "endDate": "2018-10-01T17:00:00+01:00",
    "duration": "PT0S",
    "eventStatus": "https://schema.org/EventScheduled",
    "name": "First steps"
    ...
  }
],

Hey @nickevansuk,

After pushing our latest feed live, and re-checking the validation errors, we have 1 issue left, which is durations like above, which are listed as 0 seconds.

In Clubspark, we actually capture durations as a range (0-30mins, 30-60mins, 60-90mins, 90+)

The spec states that we must return an ISO8601 format duration, however it's also validating that this duration is non-zero.

How should we handle this?

Elsewhere, we've been able to set a min and max value (e.g. age ranges), but there doesn't seem to be the same flexibility within duration.

[nickevansuk]

Hi @dolkensp great challenge! Not something we've come across before. We've got this for distance but not more duration.

It's more tricky with duration as it's strongly tied to startDate and endDate, and is used in calculations... so maybe best not to override it at this stage.

My suggestion would be for you to raise a proposal for a new property called something like "estimatedDuration" of type QuantitativeValue and unitCode of MIN.

This follows the pattern of other duration ranges in schema.org that use QuantitativeValue:

• https://schema.org/eligibleDuration
• https://schema.org/advanceBookingRequirement
• https://schema.org/deliveryLeadTime
• https://schema.org/durationOfWarranty

And follows the property naming pattern of estimatedX:

• https://schema.org/estimatedCost (which can include minValue and maxValue)
• https://pending.schema.org/estimatedSalary (which can include minPrice and maxPrice)

If you include in your proposal a suggestion of using beta:estimatedDuration to test the property we can get it added to the beta namespace.

I would suggest that part of your proposed conformance criteria is that if estimatedDuration is provided, then endDate and duration MUST not be provided, which ensures that data is provided accurately.

[nickevansuk]

@dolkensp have added this to beta (see https://github.com/openactive/modelling-opportunity-data/issues/201) looks great!

[nickevansuk]

Best not to include "endDate" with this for now if it's a date without time: it should be a datetime for this scenario, or not included.

[nickevansuk]

Closed as moved to https://github.com/RunTogether/opendata/issues/8