Re: Cost

Sorry - I obviously misread Wes’ comment - I read it as … *so there would
be multiple *[Course]*Offers for the same Course*.

Which is the default pattern in Schema.org as represented by a Product
having multiple Offers, each with its individual pricing/availability.

 I think we are suffering in this area from the naming confusion that we
never really resolved earlier.

Perhaps if we use Course and CourseOffer the pattern we are hoping to reuse
from elsewhere in Schema would be a little more obvious.

~Richard.

Richard Wallis
Founder, Data Liberate
http://dataliberate.com
Linkedin: http://www.linkedin.com/in/richardwallis
Twitter: @rjw

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

>
> Richard, I am confused:
>
> Wes wrote
>
> ... so there would be multiple Offers for the same CourseOffering, IIUC.
>
>
> and you replied
>
> +1 Wes.
>
> A great example of the benefits of creating sub-types of established
> Schema.org types - the ‘difficult to model’ use case has already been
> handled in an established pattern.
>
>
>
> I wrote
>
> Sometimes there will be variable prices per CourseOffering, so a single
> CourseOffering needs multiple Offers.
>
>
> and you replied
>
> This diverges from the established style/pattern in Schema.org - if the
> price is different, it is a different offer.
>
>
>
> Phil
>
>
>
>
>
> On 24/02/16 11:48, Richard Wallis wrote:
>
> On 24 February 2016 at 11:05, Phil Barker <phil.barker@hw.ac.uk> wrote:
>
>>
>>
>> Yes +1 to the use of the price & priceSpecification properties from Offer
>> to specify the cost of a course.
>>
>> Often there will be one price/Offer per CourseOffering so making price a
>> property of CourseOffering makes sense.
>>
>> If CourseOffering is a subtype of Offer that would be true by default.
>
>
>> Sometimes there will be variable prices per CourseOffering, so a single
>> CourseOffering needs multiple Offers.
>>
>> This diverges from the established style/pattern in Schema.org - if the
> price is different, it is a different offer.
>
>
>> Looking at the examples (e.g. Fife Accounting), often the cost details
>> are the same for multiple CourseOfferings and are specified in a separate
>> HTML block from the CourseOfferings -- microdata and RDFa kind of struggle
>> when information about a single entity is split over several blocks of
>> HTML, so it would help if the cost could be set at Course level.
>>
>
> I understand the concerns about html formatting - in practice however
> these are often overcome by the use of meta, link, and span elements.
>
> Having pricing information at the Course level will introduce a 2nd
> pattern of mark-up that will only work if there is a single price/offer.
> This ’simpler’ pattern will also differ from the Schema.org established
> patterns.  It will I suggest introduce confusion (*which pattern do I use
> and why?*); potential for error (*I have a course with a price then add a
> CourseOffering at a different price - which wins?*).  Dependant on
> website navigation, a course description could potentially be on a separate
> page to that of Offer(s) for that course - separating prices from offers is
> also potentially error prone.
>
> As previously mentioned, if there is
>
>>
>> What does this give us?
>>
>> Course needs an offers property
>>
> Would get it from CreativeWork
>
>
>> CourseOffering needs an offers property
>>
> Disagree see above
>
> For simplicity it would help if CourseOffering had a price property
>>
> Disagree - not necessary and could cause error/confusion
>
>
>> If CourseOffering is a subtype of Offer, it seems strange that there
>> should be multiple offers of an Offer, but actually
>> http://schema.org/AggregateOffer gives a pattern that does just this.
>>
>> A useful Type, that could be used but, for reasons I describe above,
> supported by your strange feelings, I don’t believe it should be on Offer
> or any of its subtypes.
>
>
>> Does that work for everyone?
>>
>
> Not quite for me.
> ~Ricard.
>
>>
>> Phil
>>
>> On 18/02/16 11:55, Richard Wallis wrote:
>>
>> +1 Wes.
>>
>> A great example of the benefits of creating sub-types of established
>> Schema.org types - the ‘difficult to model’ use case has already been
>> handled in an established pattern.
>>
>>
>> Richard Wallis
>> Founder, Data Liberate
>> http://dataliberate.com
>> Linkedin:  <http://www.linkedin.com/in/richardwallis>
>> <http://www.linkedin.com/in/richardwallis>
>> http://www.linkedin.com/in/richardwallis
>> Twitter: @rjw
>>
>> On 18 February 2016 at 01:05, Wes Turner < <wes.turner@gmail.com>
>> wes.turner@gmail.com> wrote:
>>
>>> http://schema.org/Offer
>>> + availabilityStarts
>>> + availabilityEnds
>>> + eligibleDuration
>>> * priceSpecification
>>> + priceValidUntil
>>>
>>> http://schema.org/PriceSpecification
>>> + validFrom
>>> + validTo
>>>
>>> ... so there would be multiple Offers for the same CourseOffering, IIUC.
>>>
>>> On Feb 17, 2016 6:10 PM, "Developer, SleepingDog" <
>>> <developer@sleepingdog.org.uk>developer@sleepingdog.org.uk> wrote:
>>> >
>>> > Hi all
>>> >
>>> > I think there is a case where a cost may be associated with (vary
>>> dependent upon) a date.
>>> >
>>> > For example, the W3CDevCampus courses may be launched with an “early
>>> bird” offer rate:
>>> > https://www.w3.org/blog/news/archives/5293
>>> >
>>> > Perhaps that is too difficult to model.
>>> >
>>> > Tavis
>>> >
>>> > > On 10 Feb 2016, at 15:19, Phil Barker <phil.barker@hw.ac.uk> wrote:
>>> > >
>>> > > Hello Alan,
>>> > > yes, you're absolutely right that cost can be very difficult.
>>> >
>>> >
>>>
>>
>>
>>
>> --
>> --
>> Phil Barker           @philbarker
>> LRMI, Cetis, ICBL     http://people.pjjk.net/phil
>> Heriot-Watt University
>>
>> Ubuntu: http://xkcd.com/456/
>>   not so much an operating system as a learning opportunity.
>>
>>
>
>
> --
> --
> Phil Barker           @philbarker
> LRMI, Cetis, ICBL     http://people.pjjk.net/phil
> Heriot-Watt University
>
> Ubuntu: http://xkcd.com/456/
>   not so much an operating system as a learning opportunity.
>
>