Re: Cost

On 24 February 2016 at 12:26, Phil Barker <phil.barker@hw.ac.uk> wrote:


> In particular a different price does not create a different course section
> / course presentation (think of all the different prices associated with a
> university course in the UK, at HW we charge different prices for Scottish
> & European students, non-Scottish UK students, and the rest of the world).
>
> Again there is an established pattern (not yet fully Course-compatible so
would need enhancing with more eligibility types) that handles this kind of
thing on Offer, using the eligible* properties.

Offer associates a single price with a specific intersection on a
potentially complex matrix of availability [date based, location based,
delivery type based] and eligibility criteria.

So I think there is need for multiple offers per CourseOffering unless we
> ignore complex pricing structures. Following the pattern of AggregateOffer
> seems a reasonable way of converging the domain understanding of a course
> section with schema.org's structures.
>

I don’t think we should ignore complex pricing structures, but should try
to handle them in a consistent manner.

If we follow the multi-offers per offer suggestion, data consumers/systems
will need to decide which pattern, or combinations of patterns, is in use
to be able identify all permutations of offers for a course.  Whereas a
single price per offer pattern, would reflect current Schema practices.  It
will also directly relate each individually priced offer to its associated
Course.

Whichever approach is taken will result in the same number of permutations.

~Richard