Re: Course, a new dawn?

On 26 February 2016 at 11:02, Phil Barker <phil.barker@hw.ac.uk> wrote:
>
>
> Thank you all for your replies. I will create an alternative based on
> Vicki's ideas for comparison (but not today).
>
> A could of points to clarify / question
>
> 1) I am still seeing conflicting ideas about whether Course (the abstract)
> should be a type of Creative Work. Vicki suggests this, Dan seems not so
> comfortable with it.  I know that in the bibliographic world people are
> quite comfortable with CreativeWorks being represented at an abstract level
> not just being something like a document.

I am mainly concerned about multiple super-typing with CreativeWork
and Event since the former already have lots of events associated with
them (creation, publication etc.); it feels like a recipe for
confusion.

> 2) The name of a concrete offering/presentation of the Course is
> troublesome. Every suggestion I have seen seems to lead to
> misunderstandings. Session is another one: when I teach a course we have
> sessions on Mondays and Thursdays... but that is not what is meant by Vicki.
> Offering is confusing with Offer. Section and Presentation can also lead to
> problems.  Often when we are describing what we mean we talk about the
> abstract course and a specific instance of it, so I am going to suggest we
> go with Course and CourseInstance.

That seems enough for us to use for communication. Maybe inspiration
will strike later for a better name...

Dan

> Phil
>
>
> On 25/02/16 19:30, Developer, SleepingDog wrote:
>>
>> I agree with (+1) Vicki and Dan that there is a requirement to model
>> abstract courses that are not events; which in turn may have zero, one or
>> more event-based offerings (possibly simultaneously, overlapping,
>> sequentially) with properties whose distinctiveness will be important for
>> learners.
>>
>> In markup terms, I expect this to be typically realized by a course
>> details page which contains a set of (often descriptive) abstract course
>> elements which apply to all offerings, and an optional set of offerings
>> which have properties specific to them.
>>
>> I am not familiar enough with schema.org best practice to say how this
>> should be achieved, and nor do I want to rule out a pattern that represents
>> courses as abstraction-only or as creative works (like a learning object),
>> or a one-off course which occurs as one event. But I can say that all of the
>> three student record systems I have worked on extracting course information
>> with, and all of the course modelling standards I have encountered have had
>> a (parent) abstract course and a (child) concrete offering structure.
>>
>> Tavis Reddick
>>
>>> On 25 Feb 2016, at 18:33, Dan Brickley <danbri@google.com> wrote:
>>>
>>> On 25 February 2016 at 18:23, Vicki Tardif Holland <vtardif@google.com>
>>> 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.
>>>> - Vicki
>>>
>>> +1 …Courses do indeed have
>>> aspects (especially their syllabus) which are closer to documents, and
>>> aspects which are closer to events, but we lose too much by flattening
>>> everything into a single Course type that subclasses both.…
>>> --Dan
>>>
>>
>>
>
>
> --
> --
> 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.
>
>

Received on Friday, 26 February 2016 11:17:31 UTC