- From: Phil Barker <phil.barker@hw.ac.uk>
- Date: Fri, 26 Aug 2016 10:50:11 +0100
- To: Alan Paull <alan@alanpaull.co.uk>, Jim Goodell <jgoodell2@yahoo.com>, Dan Brickley <danbri@google.com>
- Cc: "public-schema-course-extend@w3.org" <public-schema-course-extend@w3.org>
- Message-ID: <6cfcb499-f443-909e-acd9-e0a4fbb848ee@hw.ac.uk>
Hello Jim, Alan, everyone. We should decide whether we delay proposing courseMode and courseCode for inclusion in the schema.org core. Thoughts on that would be most welcome. My 2 cents on the issues: courseMode, yes, this deliberately addresses several difficult to separate aspects of a course, for the sort of reasons that Alan describes below. I see it as an example of the sort of compromise that needs to be made when trying to create a schema that works across many different contexts with providers who are, let us say, half-engaged (i.e. not using this schema as their primary means of encoding important data). I agree that a controlled vocabulary/enumeration would be hugely beneficial. I also think that it would address some of Jim's concerns while keeping the current breadth/impurity of meaning. For example couseMode : online == VirtualIndicator : True (if I understand what you mean by 'virtual') courseMode : selfPaced == CourseInteractionMode : Asynchronous However (assuming we take single courseMode approach), the question is whether we delay putting courseMode into schema until we develop the controlled vocabulary. I think that would be a significant delay. courseCode: The use case is "to find information about a specific identified course: the searcher is interested in information about known course, for example one on which they have already enrolled. The course may be identified by provider/name or by a course code." https://www.w3.org/community/schema-course-extend/wiki/Outline_use_cases#Use_case_3_find_information_about_a_specific_identified_course. I would be happy to change the description of the term to "The identifier used by the provider of the Course when advertising its availability" I think this distinguishes it from other identifiers use, for example, in returning stats about the course (which anyway is out of scope for this work). It also makes it clear that it is the providers identifier, not people offering enrolment to specific instances (again, implied as it is a property of Course not CourseInstance). [BTW, Alan, for that specific example, yes Bristol use the UCAS code when advertising the course.] Again, in longer term there might be more refined approaches. See Richard's comment at https://github.com/schemaorg/schemaorg/issues/1286#issuecomment-239119409 suggesting a IdentifierSpecification with identifierType and identifierValue properties. If this is introduced at schema level we can subsequently make courseCode a subtype of a more generic identifierValue and extend its range appropriately, if desired. Again, further thoughts most welcome. Phil On 26/08/2016 08:49, Alan Paull wrote: > > courseMode > > I think that a key problem might be current usage. > > We found with XCRI-CAP that when we introduced 3 elements along the > lines you’ve indicated below - attendanceMode (the type of location at > which the student will undertake the instance), attendancePattern (the > period in the day and/or frequency during which attendance at a venue > is required) and studyMode (a general expression of the overall > amount of the student's time that is devoted to the course) – we found > that it was very difficult for providers to supply this breakdown > automatically. This was typically because they might hold the > information as, for example, “3 years full-time, up to 6 years > part-time”, where there was a muddle over full-time/part-time > **attendance** versus full-time/part-time **study**. > > Although it’s not a pure solution, and I would prefer folks to be able > to supply and use a breakdown of the information, I think that for > practical purposes, we should opt for courseMode as defined. It has > the merit of permitting providers to enter the information in whatever > human-readable format they have at present. If we attempt to define > the breakdown, I think we may stall the design and possibly take-up. > > courseCode > > In my view this should be purely an identifier, preferably the > provider’s identifier. I was a little wary of the example we’ve used, > which was a UCAS (UK admissions) course code that is often confused > with a subject classification code; but UK providers often use these > as their own identifiers, particularly on the web. > > I have presumed (?!) that the purpose of the courseCode is to enable > the user to uniquely identify the course within a provider’s > offerings, typically in order to find more information, and to clearly > differentiate one course from another. Perhaps we need to be clearer > about the purpose of this item? I wouldn’t want to see a CIP code > here, because a CIP code is not simply a course identifier, but has a > specific subject-related meaning. > > There’s no reason (I think) that a courseCode couldn’t be a URI. For > XCRI-CAP we specifically enable that approach. > > Alan > > -- > > Alan Paull > > APS Ltd > > 80 Fenton Road, Warboys, HUNTINGDON, PE28 2SL, UK > > alan@alanpaull.co.uk <mailto:alan@alanpaull.co.uk> > > 07977 120886 > > Skype: alanepaull > > http://www.alanpaull.co.uk > > *From:*Jim Goodell [mailto:jgoodell2@yahoo.com] > *Sent:* 25 August 2016 22:16 > *To:* Dan Brickley <danbri@google.com>; Phil Barker <phil.barker@hw.ac.uk> > *Cc:* public-schema-course-extend@w3.org > *Subject:* Re: schema course extend: Progress! > > The proposed terms look good for inclusion. I just have some concerns > for usability of two of the terms. > > > > This is not necessarily to hold up the planned inclusion in the core > of the next release. It could be that they go in as is and more > terms/example/guidance added later to make them more usable. > > *CourseInstance > courseMode* (http://schema.org/courseMode) — What’s > expected here isn’t clear by the definition. A controlled vocabulary > or more refined examples could help. Current examples are about > different things: > > * Event scheduling, e.g. “Evenings only and weekends,” > > * level of student effort, e.g. “Full Time,” > > * delivery model or student experience, e.g. “MOOC,” “Online”. > > > This term seems to be trying to serve the purpose of multiple terms > such as: > > * Virtual Indicator — (Yes/No) (https://ceds.ed.gov/element/001160) > * Course Interaction Mode — (Synchronous/Asynchronous) (See: > https://ceds.ed.gov/element/001311) > * Course Instruction Method — (Lecture/Lab/Seminar/Independent > Study…) (See: https://ceds.ed.gov/element/001308 ) > * Blended Learning Model Type (Rotation model/Flex model/A La Carte > model/Enriched Virtual model) (https://ceds.ed.gov/element/001287) > * Course Section Time Required For Completion — (See: > https://ceds.ed.gov/element/000101 ) > > "courseMode," if included, should be defined as one of these in the > definition or examples, leaving to future terms added later to address > other possible meanings of "mode". > > > > *Course > courseCode* ( http://schema.org/courseCode > <http://schema.org/courseCode>) — This looks like it is assumed to be > the provider or delivery system’s course code. This text has no > standard meaning. However, a “Course Code System” in the markup could > specify if the code is either local (no global meaning) or based on a > recognized standard such as the NCES and CIP Codes used by U.S. > postsecondary institutions. > (http://nces.ed.gov/ipeds/cipcode/browse.aspx?y=55). > > > > An alternative: Just add “URL” as one of the expected types so the > markup can include a link to the standard code (e.g. > http://nces.ed.gov/ipeds/cipcode/cipdetail.aspx?y=55&cipid=87981) > > -Jim > > ------------------------------------------------------------------------ > > *From:*Dan Brickley <danbri@google.com <mailto:danbri@google.com>> > *To:* Phil Barker <phil.barker@hw.ac.uk <mailto:phil.barker@hw.ac.uk>> > *Cc:* "public-schema-course-extend@w3.org > <mailto:public-schema-course-extend@w3.org>" > <public-schema-course-extend@w3.org > <mailto:public-schema-course-extend@w3.org>> > *Sent:* Friday, August 19, 2016 9:40 AM > *Subject:* Re: schema course extend: Progress! > > > On 19 August 2016 at 10:09, Phil Barker <phil.barker@hw.ac.uk > <mailto:phil.barker@hw.ac.uk>> wrote: > > Hello all, > > > > this is a request to approve the proposal that the most stable parts > of our > > work so far into the core of schema.org. More detail about this are at > > > https://github.com/schemaorg/schemaorg/issues/195#issuecomment-240729669 > but > > in brief: > > > > Dan Brickley asked me what Course-related terms I felt were most > stable. He > > wishes to show some tangible progress and to stabilize the building > blocks > > that we will need later (and so do I). > > > > We agreed that > > * Course + properties: courseCode, coursePrerequisites, > hasCourseInstance > > * CourseInstance + properties: courseMode, instructor > > are at a stage where we can consider moving them into the schema.org > core. > > > > After yesterday's discussion, I think we can now add > > educationalCredentialAwarded to that list. > > > > So, please review > > http://pending.webschemas.org/Course > > http://pending.webschemas.org/courseCode > > http://pending.webschemas.org/coursePrerequisites > > http://pending.webschemas.org/educationalCredentialAwarded > > http://pending.webschemas.org/hasCourseInstance > > http://pending.webschemas.org/CourseInstance > > http://pending.webschemas.org/courseMode > > http://pending.webschemas.org/instructor > > > > and indicate whether you agree that these should be proposed for > inclusion > > in the core of the next release of schema.org. > > In my schema.org webmaster / community group chair capacity, I asked > "please share whatever progress you've made with the wider community > and propose the pieces with rough consensus for inclusion at > schema.org". I'm glad to see that happening. It will build confidence > in the process of developing these vocabularies this if people see > results starting to emerge. > > As a Google representative here, I can also share a little perspective > from Google as potential users of the courses vocabulary. Firstly, we > agree that these basic 8 terms are ready to be added to the schema.org > core. We have been following this work with interest as it evolves, > and are comfortable with the general direction (including the > expectation of richer credential modeling to follow) and with these > specifics. The courseMode property is naturally of special interest to > us as it is important for any applications based on this data that > some basic distinctions between offline vs online can be made without > too much guesswork, even though there are plenty of nuances that might > be explored. We would ideally like to see controlled values agreed for > this property, as consensus emerges, but believe that the basic > meaning of the property is clear enough for courseMode to already be > of value, i.e. it can be improved in-place (as happens with many other > schema.org properties as designs evolve). > > BTW thanks everyone for getting us this far. It seems we are close to > passing an important milestone in this work. > > cheers, > > > > Dan > -- Phil Barker @philbarker LRMI, Cetis, ICBL http://people.pjjk.net/phil Heriot-Watt University Workflow: http://www.icbl.hw.ac.uk/~philb/workflow/
Received on Friday, 26 August 2016 09:50:55 UTC