Re: Course, a new dawn?

On Thu, Feb 25, 2016 at 1:30 PM, Developer, SleepingDog <
developer@sleepingdog.org.uk> 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 the current schema doc,
I went through and tried to find ~similar classes with already-defined
properties that already have domains and ranges.

So, for example,

iff Course < [..., Event>

Then course.name = event_00.name and course.url == event_00.url


>
> 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.
>

Why do I want to model this as classes (with mixins), in Python, and
generate and validate these schema (classes, properties, enumerations) from
said Classes with appropriate metadata.

How do I know that it works on the other side?



>
> 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.

> Course < [CourseUnit, Event]
> CourseUnit < CreativeWork
> Course.syllabus = rdf:list(CourseUnit, CreativeWork)

With course subheadings as syllabus CourseUnit.name,
there does need to be traversal logic
that doesn't need to be different for Course and CourseUnit;
so Course.syllabus may be a sticking point if for sub-CourseUnits it's
CourseUnit.units.



> 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
> >
>
>
>
>