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.

I did that, thank you.


> This would avoid the delay, but open the door to less ambiguous tagging.
> Great work Phil and everyone!
> Jim
> ------------------------------------------------------------------------
> *From:* Phil Barker <>
> *To:* Alan Paull <>; Jim Goodell 
> <>; Dan Brickley <>
> *Cc:* "" 
> <>
> *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 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." 
> 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 
> 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
> <> 
> <>
> 07977 120886
> Skype: alanepaull
> <>
> *From:*Jim Goodell []
> *Sent:* 25 August 2016 22:16
> *To:* Dan Brickley <> <>; 
> Phil Barker <> <>
> *Cc:* 
> <>
> *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* ( — 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) (
>   * Course Interaction Mode — (Synchronous/Asynchronous) (See:
>   * Course Instruction Method — (Lecture/Lab/Seminar/Independent
>     Study…) (See: )
>   * Blended Learning Model Type (Rotation model/Flex model/A La Carte
>     model/Enriched Virtual model) (
>   * Course Section Time Required For Completion — (See:
> )
> "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* ( 
> <>) — 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. 
> (
> An alternative: Just  add “URL” as one of the expected types so the 
> markup can include a link to the standard code (e.g. 
> -Jim
> ------------------------------------------------------------------------
> *From:*Dan Brickley < <>>
> *To:* Phil Barker < <>>
> *Cc:* " 
> <>" 
> < 
> <>>
> *Sent:* Friday, August 19, 2016 9:40 AM
> *Subject:* Re: schema course extend: Progress!
> On 19 August 2016 at 10:09, Phil Barker < 
> <>> 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 More detail about this are at
> > 
> 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 
> core.
> >
> > After yesterday's discussion, I think we can now add
> > educationalCredentialAwarded to that list.
> >
> > So, please review
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > and indicate whether you agree that these should be proposed for 
> inclusion
> > in the core of the next release of
> In my 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
>". 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
> 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
> 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
> Heriot-Watt University
> Workflow: 
> <>

Phil Barker           @philbarker
Heriot-Watt University


Received on Wednesday, 7 September 2016 09:16:20 UTC