Re: Course, a new dawn?

On Thu, Feb 25, 2016 at 1:53 PM, Wes Turner <wes.turner@gmail.com> wrote:

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

https://docs.google.com/document/d/12YWjLzZC8FiTiOwSAETRIEozeqZdn6O8a4fgqK4t5Ss/edit#heading=h.rfn4nr6j1toq

There are lots of comments in the sidebar of this doc that are not cc'ed to
the mailing list.

This doc:

* could be a sheet (with a transform to CSV, and then a transform to [RDFa])
* does not define domain, range, and [subclass,es] in a separate column


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