Re: schema course extend: Progress!

No need for my concerns to get in the way of progress; here's my 2 cents:
Go ahead with courseCode, but preferably adding "URL" as an expected type along with "Text," so then a text value could be assumed to be a provider code with only local meaning, and a URL can point to an item in a standard code-set with parse-able definition/context.
Go ahead with courseMode as an overloaded term only if "URL" is added as an expected type for reference to terms in an external controlled vocabulary.

The definition could be extended to provide some guidance such as:  

The medium or means of delivery of the course, or the mode of study, either as a text label (e.g. "online", "onsite", or "blended"; "synchronous" or "asynchronous"; "full-time" or "part-time") or as a URL reference to a controlled vocabulary (e.g. https://ceds.ed.gov/element/001311#Asynchronous).

This would avoid the delay, but open the door to less ambiguous tagging.


Great work Phil and everyone! 
Jim

      From: Phil Barker <phil.barker@hw.ac.uk>
 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>
 Sent: Friday, August 26, 2016 5:50 AM
 Subject: Re: schema course extend: Progress!
   
 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 athttps://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:
  
 
#yiv9533999549 #yiv9533999549 -- _filtered #yiv9533999549 {font-family:Helvetica;panose-1:2 11 6 4 2 2 2 2 2 4;} _filtered #yiv9533999549 {font-family:Wingdings;panose-1:5 0 0 0 0 0 0 0 0 0;} _filtered #yiv9533999549 {panose-1:2 4 5 3 5 4 6 3 2 4;} _filtered #yiv9533999549 {font-family:Calibri;panose-1:2 15 5 2 2 2 4 3 2 4;}#yiv9533999549 #yiv9533999549 p.yiv9533999549MsoNormal, #yiv9533999549 li.yiv9533999549MsoNormal, #yiv9533999549 div.yiv9533999549MsoNormal {margin:0cm;margin-bottom:.0001pt;font-size:12.0pt;}#yiv9533999549 a:link, #yiv9533999549 span.yiv9533999549MsoHyperlink {color:blue;text-decoration:underline;}#yiv9533999549 a:visited, #yiv9533999549 span.yiv9533999549MsoHyperlinkFollowed {color:purple;text-decoration:underline;}#yiv9533999549 span.yiv9533999549EmailStyle17 {color:#1F497D;}#yiv9533999549 .yiv9533999549MsoChpDefault {font-size:10.0pt;} _filtered #yiv9533999549 {margin:72.0pt 72.0pt 72.0pt 72.0pt;}#yiv9533999549 div.yiv9533999549WordSection1 {}#yiv9533999549 _filtered #yiv9533999549 {} _filtered #yiv9533999549 {font-family:Symbol;} _filtered #yiv9533999549 {} _filtered #yiv9533999549 {font-family:Wingdings;} _filtered #yiv9533999549 {font-family:Wingdings;} _filtered #yiv9533999549 {font-family:Wingdings;} _filtered #yiv9533999549 {font-family:Wingdings;} _filtered #yiv9533999549 {font-family:Wingdings;} _filtered #yiv9533999549 {font-family:Wingdings;} _filtered #yiv9533999549 {font-family:Wingdings;} _filtered #yiv9533999549 {} _filtered #yiv9533999549 {font-family:Symbol;} _filtered #yiv9533999549 {} _filtered #yiv9533999549 {font-family:Wingdings;} _filtered #yiv9533999549 {font-family:Wingdings;} _filtered #yiv9533999549 {font-family:Wingdings;} _filtered #yiv9533999549 {font-family:Wingdings;} _filtered #yiv9533999549 {font-family:Wingdings;} _filtered #yiv9533999549 {font-family:Wingdings;} _filtered #yiv9533999549 {font-family:Wingdings;}#yiv9533999549 ol {margin-bottom:0cm;}#yiv9533999549 ul {margin-bottom:0cm;}#yiv9533999549  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 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) — 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>
 To: Phil Barker <phil.barker@hw.ac.uk> 
 Cc: "public-schema-course-extend@w3.org" <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> 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/