- From: Phil Barker <phil.barker@hw.ac.uk>
- Date: Mon, 15 Feb 2016 11:01:14 +0000
- To: Jim Goodell <jgoodell2@yahoo.com>, "public-schema-course-extend@w3.org" <public-schema-course-extend@w3.org>
- Message-ID: <56C1AFFA.2040609@hw.ac.uk>
OK, I get the message that dropping CourseOffering is not an option.
An alternative to reproducing all the Course properties in
CourseOffering would be to mark up single offering Courses as both
Course and CourseOffering, e.g.
<div vocab="http://schema.org/" typeof = "Course, CourseOffering">
I'll try to work up some examples.
Phil
On 12/02/2016 14:12, Jim Goodell wrote:
> 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
> <http://course.schema-course-extend.appspot.com/Course> metadata with
> optional enumeration of CourseSections
> <http://course.schema-course-extend.appspot.com/CourseSection>
>
> <http://course.schema-course-extend.appspot.com/CourseSection>
> 2. Markup for a single offering CourseSection
> <http://course.schema-course-extend.appspot.com/CourseSection> that
> includes relevant properties of Course
>
>
>
>
> *MailScanner has detected a possible fraud attempt from
> "course.schema-course-extend.appspot.com" claiming to be* Course -
> course.schema.org <http://course.schema-course-extend.appspot.com/Course>
> Schema.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.
>
> *MailScanner has detected a possible fraud attempt from
> "course.schema-course-extend.appspot.com" claiming to be* View on
> course.schema-course-extend.appspot.com
> <http://course.schema-course-extend.appspot.com/Course>
>
> Preview by Yahoo
>
>
>
>
>
>
> *MailScanner has detected a possible fraud attempt from
> "course.schema-course-extend.appspot.com" claiming to be*
> CourseSection - course.schema.org
> <http://course.schema-course-extend.appspot.com/CourseSection>
> Schema.org: CourseSection - An instance of a Course offered by zero or
> more instructors.
>
> *MailScanner has detected a possible fraud attempt from
> "course.schema-course-extend.appspot.com" claiming to be* View on
> course.schema-course-extend.appspot.com
> <http://course.schema-course-extend.appspot.com/CourseSection>
>
> 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=*MailScanner has detected a possible fraud attempt from
> "schema.org" claiming to be* "http://schema.org/" <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": *MailScanner has detected a possible fraud attempt
> from "schema.org" claiming to be* "http://schema.org/"
> <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, ICBLhttp://people.pjjk.net/phil
> Heriot-Watt University
>
> Ubuntu:http://xkcd.com/456/
> not so much an operating system as a learning opportunity.
>
>
--
Phil Barker @philbarker
LRMI, Cetis, ICBL http://people.pjjk.net/phil
Heriot-Watt University
Workflow: http://www.icbl.hw.ac.uk/~philb/workflow/
-----
We invite research leaders and ambitious early career researchers to
join us in leading and driving research in key inter-disciplinary themes.
Please see www.hw.ac.uk/researchleaders for further information and how
to apply.
Heriot-Watt University is a Scottish charity
registered under charity number SC000278.
Received on Monday, 15 February 2016 11:01:56 UTC