Khan Academy in LR

[joe hobson]

There was talk a few months ago about someone putting all of the Khan Academy resources into the LR, in LRMI no less, including the CCSS alignments. I think i even heard rumor that someone (Jim Klo, maybe?) already had it in place on their dev node. Is this true? If so, can we get these records up on a public node so others can make use of them? Would be greatly appreciated by a few edu systems we work with.

-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-

joe hobson, owner / director of technology & innovation

   Navigation North Learning Solutions

[joe hobson]

There are some LRMI records on the sandbox server, mostly Khan Academy stuff that Jim has been working on: https://sandbox.learningregistry.org/slice?any_tags=LRMI

I'm still not convinced that LRMI lends itself well to being used as a full metadata schema, or that it offers advantages over using NSDL DC. I think the hope is that it will become so widely accepted and consumable that it will be the preferred schema. It's probably worth your time to put together an LRMI payload for some of your resources and compare to the NSDL DC version to see if it's worth changing your system's preference. 

On Feb 1, 2013, at 12:39 PM, Michael Parsons wrote:

Speaking of LRMI, as yet, we have not seen any documents imported from the Learning Registry with a schema of LRMI.

We understand that the Shared Learning Collaborative (SLC) will be publishing using LRMI.

 We are doing our test publishing using the NSDL Dublin core schema. Should we instead use LRMI?

 That is will LRMI become the preferred schema?

Michael Parsons
Solution Architect

Illinois workNet (TM)

--
You received this message because you are subscribed to the Google Groups "Learning Registry Developers List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to learningreg-d...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Jerome Grimmer]

I have a couple questions for you all.

·         I’ve noticed that metadata in the LR tends to be in XML format, while paradata tends to be in JSON format.  I’ve written my import mostly around this assumption.  Now it looks like the LRMI metadata that Jim has made available in the sandbox is in JSON format.  I can certainly tweak my ETL process to watch out for this, but would like to know if the current LRMI metadata format is the one that will be used in production, or if it is going to change.

·         I’ve made the assumption in my ETL process that payload_schema is a single item, not an array.  I’ve noticed some items in the LR (notably Steve Lewnau’s submissions, and now the LRMI items in the sandbox that Jim is working on) have an array for the payload_schema..  For example, Steve Lewnau is putting in:
     payload_schema: [ “hashtags”, “describing”, “resource_locator”, “format”]
yet the schema he’s using is NSDL.  The payload_schema for the LRMI that is in the sandbox looks like this:
     payload_schema: [ “schema.org”, “LRMI”, “application/microdata+json”]
What is the significance of an array of payload_schemas as opposed to a single schema?  Should I be adapting my ETL process to handle this, or can I look at the first one and ignore the rest?

 

Thanks,

Jerome Grimmer

Southern Illinois University Carbondale

2450 Foundation Drive Suite 100

Springfield, IL

Phone: 217-786-3010 ext. 5857

Toll-free: 1-800-252-4822 ext. 5857

NOTE: My E-mail address has changed

jgri...@siuccwd.com

"If you think you're too small to make a difference, you've never spent a night with a mosquito." - An African Proverb

[Jim Klo]

Hi Jerome,

While still in the works and 'not ready for prime time'… I've defined a JSON Schema v3 validation for Resource Data to support the upcoming release which will support replacement documents (for update/delete)…  https://github.com/jimklo/LearningRegistry/tree/update-delete/LR/lr/schema They should be compatible with most v3 JSON Schema validators that can resolve "ref$" (other than a custom date string, however you can see how that's done here: https://github.com/jimklo/LearningRegistry/blob/update-delete/LR/lr/schema/validate.py#L125)

I may break the new validator out into it's own module such it can be used standalone, but I haven't made that decision yet.

·         I’ve noticed that metadata in the LR tends to be in XML format, while paradata tends to be in JSON format.  I’ve written my import mostly around this assumption.  Now it looks like the LRMI metadata that Jim has made available in the sandbox is in JSON format.  I can certainly tweak my ETL process to watch out for this, but would like to know if the current LRMI metadata format is the one that will be used in production, or if it is going to change.

This is a legacy issue. Most metadata that exists today just plain exists in XML. The LRMI folks have been working with Schema.org to adopt the LRMI extensions (I think this is official now, but not sure - otherwise it's very close). Schema.org is an implementation of HTML Microdata.  Working with InBloom (formerly the SLC) there was a desire for a more portable format (as HTML contains way too much data that is non-machine readable).  Microdata which is referenced by Schema.org in several places, provides a lossless Microdata to JSON transformation.  This is what was used as the basis for the work on Khan Academy, and is the agreed upon format that InBloom will be using to ingest into the LRI Browser and Search.

Activity Data, as it exists in the wild today exists as both XML and JSON. We initially started with comm_para (which is an XML backed format), but several felt it was too restrictive, and not conducive to extension.  As a second stab at this, we then work on LR Paradata 1.0 which is a JSON variant of ActivityStreams.

·         I’ve made the assumption in my ETL process that payload_schema is a single item, not an array.  I’ve noticed some items in the LR (notably Steve Lewnau’s submissions, and now the LRMI items in the sandbox that Jim is working on) have an array for the payload_schema..  For example, Steve Lewnau is putting in:
     payload_schema: [ “hashtags”, “describing”, “resource_locator”, “format”]
yet the schema he’s using is NSDL.  The payload_schema for the LRMI that is in the sandbox looks like this:
     payload_schema: [ “schema.org”, “LRMI”, “application/microdata+json”]
What is the significance of an array of payload_schemas as opposed to a single schema?  Should I be adapting my ETL process to handle this, or can I look at the first one and ignore the rest?

There is a distinct significance here. Steve's use is incorrect from what I can tell (but I haven't seen the resource data), and looks like the description of the field from the spec, "Hashtags describing the resource data format." The intent is that many formats may use multiple schemas rolled up into a custom schema (ie. NSDL_DC is Dublin Core plus some additions, so technically one could mark NSDL_DC resource data as both DC and NSDL_DC; and use a DC parser to extract just the DC bits)

For the Khan Academy work, I've marked it as you noted ( schema.org, LRMI, and application/microdata+json ) which a parser for any one of those could be used to translate all or part of the resource data.

The field that is probably more important however is "payload_schema_locator" which is the location (usually a URI) that references the exact schema for the resource data (which would be able to parse the entire payload).

Jim Klo

Senior Software Engineer

Center for Software Engineering

SRI International

e. jim...@sri.com

t. @nsomnac

p. 805.542.9330 x121

m.  805.286.1350

On Feb 5, 2013, at 9:22 AM, Jerome Grimmer <jgri...@siuccwd.com>

 wrote:

I have a couple questions for you all.

·         I’ve noticed that metadata in the LR tends to be in XML format, while paradata tends to be in JSON format.  I’ve written my import mostly around this assumption.  Now it looks like the LRMI metadata that Jim has made available in the sandbox is in JSON format.  I can certainly tweak my ETL process to watch out for this, but would like to know if the current LRMI metadata format is the one that will be used in production, or if it is going to change.

·         I’ve made the assumption in my ETL process that payload_schema is a single item, not an array.  I’ve noticed some items in the LR (notably Steve Lewnau’s submissions, and now the LRMI items in the sandbox that Jim is working on) have an array for the payload_schema..  For example, Steve Lewnau is putting in:
     payload_schema: [ “hashtags”, “describing”, “resource_locator”, “format”]
yet the schema he’s using is NSDL.  The payload_schema for the LRMI that is in the sandbox looks like this:
     payload_schema: [ “schema.org”, “LRMI”, “application/microdata+json”]
What is the significance of an array of payload_schemas as opposed to a single schema?  Should I be adapting my ETL process to handle this, or can I look at the first one and ignore the rest?

 

Thanks,

Jerome Grimmer

Southern Illinois University Carbondale

2450 Foundation Drive Suite 100

Springfield, IL

Phone: 217-786-3010 ext. 5857

Toll-free: 1-800-252-4822 ext. 5857

NOTE: My E-mail address has changed

jgri...@siuccwd.com

"If you think you're too small to make a difference, you've never spent a night with a mosquito." - An African Proverb