Re: Should we drop CourseOffering [was Re: Modelling Course and CourseOffering

I don't think CourseOffering can be dropped. However, tagging could be made simpler if CourseSection included properties from Course.

Any flattening in practice of Course and CourseOffering (AKA CourseSection) should be done at the CourseOffering level because in most cases the relevant information to the end user is answering the question "what courses can I enroll in next," i.e. what courses are available/offered to me when. Students are not as interested in the Course that is still listed in an institution's catalog, and once was offered, but will never be offered again.

There could be two mark-up models:
1. (For presenting multiple options, e.g. times/places/virtual for a single course.) Markup for the Course metadata with  optional enumeration of CourseSections
2. Markup for a single offering CourseSection that includes relevant properties of Course 

|   |
|   |   |   |   |   |
| Course - course.schema.orgSchema.org: Course - A unit of teaching where one or more instructors delivers lessons to students. Courses may be one-time meetings or meet regularly for a defined period of time. A class. |
|  |
| View on course.schema-course-extend.appspot.com | Preview by Yahoo |
|  |
|   |



|   |
|   |   |   |   |   |
| CourseSection - course.schema.orgSchema.org: CourseSection - An instance of a Course offered by zero or more instructors. |
|  |
| View on course.schema-course-extend.appspot.com | Preview by Yahoo |
|  |
|   |



      From: Phil Barker <phil.barker@hw.ac.uk>
 To: public-schema-course-extend@w3.org 
 Sent: Thursday, February 11, 2016 1:33 PM
 Subject: Should we drop CourseOffering [was Re: Modelling Course and CourseOffering
   
  
 Your comments please...
 
 
 Proposal: should we drop CourseOffering (AKA CourseSection) as a separate type from Course, and see how we fare without it. We can add it back later if we find we need it. We define Course in such a way that the properties currently discussed as relating to CourseOffering become properties of Course.
 
 Course 
 "defintion: a sequence of events and/or creative works that aims to build the knowledge, competence or ability of learners, and that may be offered at a specific time and place, or through specific mode of study."
 
 Rationale:
 
 On 10/02/16 15:48, Alan Paull wrote:
 
 On the web many course pages concatenate the concepts of overarching programme, Course and CourseOffering, such that you'd be hard pressed to prise them apart.  In addition, the difference between Course and CourseOffering is not sufficiently obvious that it makes it easier to use with both than with only one of them.

Subject to it actually working (!), I'd go for just having Thing > Intangible > Course.  However, for simplicity of explanation I'd define it using the CourseOffering definition (whatever we come up with), so that it's called Course but operates like a CourseOffering. 
 
 and on 10/02/16 16:07, J Marks wrote:
  
 
 > - is there a need for a separate type for the instantiation? 
  Is there a strong reason to separate this? Seems cleaner to not if we don;t have a strong reason to, and I don't have one to offer.  
   
 
 What we have by reason so far comes from the use cases at https://www.w3.org/community/schema-course-extend/wiki/Outline_use_cases which lead to requirement p: "must be able to identify web pages that describe specific instances of a course being offered". These are essentially along the lines of "refining the search for a course by some factor such as Cost, Mode of study, Location that may vary between CourseOfferings.  We offer all this information as repeated properties of Course. 
 
 Example:
 An example course
 Offered online for Free or face-to-face for $100.
 
 in RDFa
 <div vocab="http://schema.org/" resource="#record" typeof = "Course">
 <h1 property="name">An example course</h1>
 Offered 
  <span property="modeOfStudy">online</span> 
  for <span rel="offers" typeOf="Offer"><meta property="price" content="0">Free</meta></span> or 
  <span property="modeOfStudy">face-to-face</span> 
  for <span rel="offers" typeOf="Offer"><meta property="priceCurrency" content="USD" />$<span property="price" value="0">100</span></span> 
 </div>
 
 in JSON-LD
 {
     "@context": "http://schema.org/",
     "@type": "Course",
     "name": "An example course",
     "schema:modeOfStudy": [
         "online",
         "face-to-face"
     ],
     "schema:offers": [
         {
             "@type" : "Offer",
             "schema:price": "100",
             "schema:priceCurrency": "USD"
         },
         {
             "@type" : "Offer",
             "schema:price": "0"
         }
     ]
 }
 
 
  The case against: 
 the implication would be that we wouldn't know which cost related to which mode of study / location etc. Someone searching for a free face-to-face course wouldn't know whether the free course on offer was for face to face or online.  In mitigation:
   1. My experience is that same as Alan's, that mostly web pages in real life show one offering per page.
   2. I am pretty sure that we could come up with patterns that deal with the cases of several offerings of the same course, perhaps by making the Offer the main entity and using the itemOffered property to point to the different modes of study as different courses.
   3. If 2 doesn't work out, we could go back to seeing whether a differently conceptualised CourseOffer as a subclass of Offer would work.
 (if 2 and 3 don't work out we put CourseOffering back in)
 
 Phil
 
 -- 
--  
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.