Re: Course, a new dawn?

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

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

With such a spreadsheet, we could avoid re-work (and be more DRY) in
defining e.g. class/property descriptions; because currently I have no idea
which descriptions have been modified since I drafted course.rdfa in #972.

This doc:

* could have a column "_" for schemaType (e.g. "C" for class, and "P" for
property; as in OWL)


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