Re: Course, a new dawn?

1) I'm comfortable that Course (the abstract) is a CreativeWork.2) I'm comfortable with CourseInstance for the instance (a.k.a. Section/Offering) in this context.  

(CourseInstance could then use existing schema Offer and Event properties to handle those aspects without confusion.)
Jim

      From: Phil Barker <phil.barker@hw.ac.uk>
 To: public-schema-course-extend@w3.org 
 Sent: Friday, February 26, 2016 6:02 AM
 Subject: Re: Course, a new dawn?
   


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.

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.

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.