W3C home > Mailing lists > Public > public-vocabs@w3.org > June 2012

Re: (most likely) Version 1.0 of LRMI specification - proposed for inclusion with Schema.org

From: Phil Barker <phil.barker@hw.ac.uk>
Date: Fri, 15 Jun 2012 20:01:19 +0100
Message-ID: <4FDB867F.5030306@hw.ac.uk>
To: lrmi@googlegroups.com
CC: Monty Swiryn <mswiryn@gmail.com>, public-vocabs@w3.org

Hello

On 15/06/12 19:20, Monty Swiryn wrote:
>
>   * The most obvious:  There does not appear to be a "Subject"
>     property.  There needs to be a property to indicate the main
>     subject area (aka curriculum area) of the product. Examples, of
>     course, are "Social Studies", "Science", etc.
>

This one is simple: the 'about' property that comes with schema.org 
creative work already does this. LRMI only adds properties that are 
needed but not already covered.

>   * There is a typicalAgeRange property, but no property for grade
>     level.  Educators have different definitions for "grade level" vs
>     "age range".  Many educational products are developed for use in a
>     specific grade level, but designed for students who may be older
>     or younger than the typical age for that grade.  In addition, many
>     of the publishers with whom we work tag their products with a
>     variety of "levels." These include "reading level" and "interest
>     level," as well as some well-known classifications as "Guided
>     Reading Level," "Reading Recovery Level," and "Lexile Level." 
>     Many educators value the ability to search for products by these
>     categories.  It is not apparent that these criteria are included
>     in typical standards alignment hierarchies.
>
These can all be values of the alignmentType property of the 
AlignmentObject used to describe the educationalAlignment. You mention 
below that common core / state standards don't include these, but the 
value of educationalType is not limited by these.

>   * There is a concern that publishers and educators in other
>     countries may have needs for other "level" classifications, such
>     as the levels of the International Baccalaureate program used by
>     most British schools.
>
(err, no it isn't. A very small minority of British school offer the IB, 
most work to the National Curriculum and offer GCSE and A levels.)

On the broader point, yes, there is a plethora of different approaches 
to level. I think that educationalAlignment with alignmentType set as 
educationLevel is the way to deal with these. More specific 
alignmentTypes may be identified through use.


>   * However,  this can be taken care of as a data problem rather than
>     a schema properties problem.  Publishers of materials for these
>     programs can use a "grade level" property to indicate criteria
>     such as "sixth-formers" or "MYP"  - terms that their education
>     customers look for.  Simply using age level won't due in these cases.
>   * What about the issue of "accessibility"?  In the K-12 market, it
>     is common to align resources to be compliant with Section 508
>     Amendment to the Rehabilitation Act of 1973. Does the proposed
>     schema account for this area?
>
No. Accessibility is not specifically and educational issue, I think 
experts in accessibility should address this.


I can't really comment on the later points you raise.

Regards, Phil

>  *
>   * These are probably some of the most (if not _the_ most) important
>     search criteria that K-12 educators use to locate resources. It's
>     obvious, intuitive and well-documented that a 7th grade science
>     teacher would begin a search for products by looking for resources
>     where the subject is "science" and the grade is "7".
>
> There is an argument that criteria such as subject or grade level is 
> part of the "educationalAlignment" property.  There are some 
> problematic issues with this assumption:
>
>   * As mentioned above, typical state and common core standards do not
>     include things such as "Guided Reading Level," "Reading Recovery
>     Level," and "Lexile Level."  Publishers who are using these terms
>     to classify their resources do so because their customers search
>     for resources by these categories.  Here's an example:
>     www.newbridgeonline.com/search.html
>   * Aligning products to state or common core standards is typically a
>     huge undertaking.  While some publishers have correlated their
>     products to these standards, from our experience many of the
>     smaller publishers are not prepared to spend the time and money to
>     embark on this type of effort.  Consider that a typical standards
>     schema has hundreds or thousands of specific standards.  Even
>     these smaller publishers can have thousands of products.  Further,
>     a single resource may be correlated with dozens of these
>     standards. Correlating these resources to the standards is clearly
>     a monumental effort in most cases. Requiring publishers to
>     correlate their products to state or common core standards
>     discriminates against publishers who cannot afford the cost and/or
>     time to do so.
>   * Searching for products aligned to state or core standards is a
>     separate issue or need for educators.  Educators may not
>     necessarily be looking for products that are aligned to standards.
>     In this case, they will use the basic criteria described above to
>     search for products and arrive at a list of products that meet
>     their search criteria.  In the case of standards, they will search
>     a standards database for the specific standards that they wish to
>     fulfill. This type of search will lead to a search result list of
>     standards.  From there, they can then view products that meet
>     those specific standards. This difference can be very subtle, and
>     may be difficult to understand for people who have not implemented
>     a standards correlation search system.  However, we have found
>     that both publishers and educators find these two different search
>     mechanisms very useful.
>   * In order to get K-12 educational publishers on board with the
>     LRMI, the LRMI must be designed to meet the needs of these
>     publishers and their customers -- educators in the K-12 school
>     setting. LRMI must take into consideration how publishers
>     currently categorize and market their products, and how educators
>     search for those products, rather than trying to force them into a
>     new system. If the publishers feel that they have to adopt and
>     implement a completely new system of representing their products,
>     they will not have the incentive to spend the time and money to
>     make the effort.  In order to arrive at a useful schema, it is
>     necessary to take into consideration the educational criteria that
>     K-12 publishers and educators value.
>
> There are other examples of product "properties" which we have found 
> that publishers and educators both require. We see no problem in 
> adding some of these common attributes to the schema.  If they are not 
> used, no harm done.  But if the schema properties that are necessary 
> and important to publishers and educators is not present, it will be a 
> huge disappointment to them.
>
> However, we understand that it is not feasible to accommodate all 
> these properties in the LRMI schema.  A suggestion, therefore, would 
> be to allow the spec to be extensible. This way publishers who have a 
> need for specific properties that are not part of the default schema 
> could add their own.
>
> Finally, as I mentioned, we have a great deal of data on the 
> categorization of K-12 educational resources and the usage patterns of 
> educators who search for these resources.  With the publishers' 
> permissions, I would be happy to present examples of this data to the 
> appropriate audience, if this would be helpful.
>
> Many thanks again for your efforts in this endeavor and for 
> considering these issues.  I apologize if this is not on point.
>
> Cheers,
> Monty


-- 
Ubuntu: not so much an operating system as a learning opportunity.
Received on Friday, 15 June 2012 19:01:55 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 15 June 2012 19:01:56 GMT