Re: schema course extend: Progress!

Just to tie up loose ends:


On 29/08/2016 23:30, Jim Goodell wrote:
> No need for my concerns to get in the way of progress;
Not a problem Jim, your suggestions /are/ 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.
>
I went ahead but did not add URL; I did change the definition to make it 
clear that the courseCode was the code used by the course provider to 
identify the course. I think we need to discuss a little more so that I 
understand what these standard code-sets are codes for. I want to avoid 
any misunderstanding that the courseCode property be used for coding 
courses against standard codes for subject etc., rather than the local 
code used as an identifier for a course (though the two can be 
conflated, as Alan mentioned in the UK the UCAS code for subject is 
often used by institutions as a local identifier).  I think if the 
course provider has a URL to identify the course they would use the url 
property for it.

We can revisit this next time around.

> 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).
>

I did that, thank you.

Phil

> 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 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
> <mailto:alan@alanpaull.co.uk>alan@alanpaull.co.uk 
> <mailto:alan@alanpaull.co.uk>
> 07977 120886
> Skype: alanepaull
> http://www.alanpaull.co.uk <http://www.alanpaull.co.uk/>
> *From:*Jim Goodell [mailto:jgoodell2@yahoo.com]
> *Sent:* 25 August 2016 22:16
> *To:* Dan Brickley <danbri@google.com> <mailto:danbri@google.com>; 
> 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>
> *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, ICBLhttp://people.pjjk.net/phil
> Heriot-Watt University
>
> Workflow:http://www.icbl.hw.ac.uk/~philb/workflow/ 
> <http://www.icbl.hw.ac.uk/%7Ephilb/workflow/>
>
>

-- 
Phil Barker           @philbarker
LRMI, Cetis, ICBL     http://people.pjjk.net/phil
Heriot-Watt University

Workflow: http://www.icbl.hw.ac.uk/~philb/workflow/