Re: Course, a new dawn?

There is a mock up of Vicki's proposal (as I understand it) at
http://course.schema-course-extend-vthprop.appspot.com/Course
http://course.schema-course-extend-vthprop.appspot.com/CourseInstance

If you scroll right down to the bottom there are a couple of examples as 
Google testing tool output (more or less human readable) and RDFa.

Are we happy to proceed with this as a general approach?

Phil

On 25/02/2016 18:23, Vicki Tardif Holland wrote:
> I am concerned that in the name of simplicity, we are losing the 
> ability to understand the various things a Course may be:
>
> 1. The abstract notion (e.g. "HNC Accounting").
> 2. A specific session of the Course (e.g. HNC Accounting taught at St 
> Brycedale Campus Kirkcaldy starting 2016-08-29).
> 3. An offer to sell access to a Course. In the online world, this is 
> usually a specific session.
>
> As the examples are written, I cannot tell the difference between 
> definitions 1) and 2), particularly because the first example gives dates.
>
> I think we need to move back to a model where there is:
>
> 1. Course which is a subtype of CreativeWork
> 2. CourseOffering (or CourseSession if Offering is too close to Offer) 
>  which is a subtype of Event
> 3. Use the "offers" property on CreativeWork and Event to allow 
> someone to specify an Offer to sell access to a Course or 
> CourseSession as appropriate.
>
> - Vicki
>
> Vicki Tardif Holland | Ontologist |vtardif@google.com 
> <mailto:vtardif@google.com>
>
> On Thu, Feb 25, 2016 at 12:47 PM, Phil Barker <phil.barker@hw.ac.uk 
> <mailto:phil.barker@hw.ac.uk>> wrote:
>
>
>     Well, that got complicated & confusing.
>
>     Richard and I had a chat this afternoon, he suggested we try
>     something different. Briefly, it is to try a new starting point
>     (and I hope I have interpreted correctly):
>
>     Do not have separate types for Course and CourseOffering.
>
>     Define Course as a subtype of both Creative Work and Event, which
>     can be used for both the abstract description and the concrete
>     instances.
>
>     Define a coursePresentation property of Course to relate the
>     concrete instances to the abstract description when necessary. (I
>     guess and inverse property might useful).
>
>     When describing a concrete instance of a course, declare it to be
>     both a Course and an Offer. This allows the use of price,
>     offeredBy, ApplyAction and so on.
>
>     There is an mock-up of this at
>     http://course.schema-course-extend-rjwprop.appspot.com/Course If
>     you scroll right down to the bottom there are a couple of examples
>     as Google testing tool output (more or less human readable) and RDFa.
>
>     Any comments on this as a general approach? Does it make enough of
>     a distinction between a Course and its
>     Sections/Presentations/Offerings for it to be clear to people who
>     care about such a distinction?
>
>     Don't worry too much about details of the properties that are
>     currently in the mock-up, that could lead more rabbit holes
>     prematurely.
>
>     Phil
>
>     -- 
>     --
>     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

Workflow: http://www.icbl.hw.ac.uk/~philb/workflow/



----- 
We invite research leaders and ambitious early career researchers to 
join us in leading and driving research in key inter-disciplinary themes. 
Please see www.hw.ac.uk/researchleaders for further information and how
to apply.

Heriot-Watt University is a Scottish charity
registered under charity number SC000278.