Paradata in 20 minutes or less

[Midgley, Steve]

https://docs.google.com/document/d/1QG0lAmJ0ztHJq5DbiTGQj9DnQ8hP0Co0x0fB1QmoBco/edit?hl=en_US

 

Please review to see what you think. Hopefully this document will be a useful intro to the full paradata spec document we’ve been working on.

 

If you want edit rights, just mail me – all are welcome. We’ll publish more broadly after a few of you have signed off that this makes sense and helps get people started on paradata.

 

All input welcome!

Steve

 

--

Steve Midgley

Deputy Director

Office of Education Technology

US Department of Education

steve....@ed.gov

 

@OfficeofEdTech

 

[Phil Barker]

Hi Steve. Looks useful to me--that is to say, I think I understand it.

The first example in the Summary section seems to have an unbalanced } at the end of the "verb", is that right?
  {
    "actor": {

"objectType": "teacher",

"description": ["high school", "physics"]},

"verb": {

"action": "bookmarked",

"context": {"id": http://www.delicious.com/"},

"date": "2011-06-01/2011-06-30"}},

Phil

-- 
<http://www.icbl.hw.ac.uk/~philb/>
Please note new email address: phil....@hw.ac.uk

---

Heriot-Watt University is a Scottish charity registered under charity number SC000278.

Heriot-Watt University is the Sunday Times Scottish University of the Year 2011-2012

[Jeffrey Hill]

It's helpful and straight-forward, much to the benefit of those who
haven't been following the development of the paradata spec as closely
(I am guilty as charged).

One part of the Quick Reference confused me a bit: the usage of
"related".

"related" refers to a collection of things that relate to the
paradata (usually the object). It is commonly an array of JSON
elements of more "objects".
["object"] -- put a bunch of objects inside related to list
their relation to the main object.

Since a resource can't be an actor, I see why it's set up this way,
but that could be clearer in the explanation. Maybe an extension of
the example with "related" that demonstrates how one could "measure"
or qualify related objects to the main objects using an assertion?

[Midgley, Steve]

Thanks – fixed. Good catch.

 

Steve

[kmentor]

If anyone could put forth a bit more info about the term "objectType"
I'd appreciate it.

I see it used in the LR paradata docs and in the Activity Streams web
site's docs. Is the term "objectType":


1) An actual element name?
2) Used generically as a one-size-fits-all name?
3) Used to imply that one should apply an appropriate term for their
"object".
4) Other.

Thanks,
Kraig


>   {

[Midgley, Steve]

I'm not personally fond of it but it's used by AS so we inherit the term.

The best way to understand what it is, is to look at json examples:

"actor": "teacher"

Vs

"actor": {"objectType":"teacher", "description":["5th grade"]}

So objectType just contains the "actor" attribute that you would have provided as a string, when you want to nest that attribute inside json that contains other elements for actor as well.

In the case of "verb" the equivalent term is "action" that plays the same function as "objectType" for actor.

In the case of "object" it's a little looser, but generally the equivalent term is "id" that contains the string that you would have provided if you just attached a string to "object"

Am I clarifying or obscuring?

Steve

[kmentor]

Ah. OK, the reference to verb/action cleared it up for me.

Thanks!
Kraig

> > "description": ["high school", "physics"]},- Hide quoted text -
>
> - Show quoted text -

[kmentor]

I've made a pass on the Paradata in 20 document located at:

https://docs.google.com/document/d/1QG0lAmJ0ztHJq5DbiTGQj9DnQ8hP0Co0x...

At the end of the document, in red text, I've added a few more
examples. A few incorporate "related" and another uses "measure".
Should anyone have the opportunity to look at them could you kindly
tell me:

1) Are they done correctly?


2) Previously in this thread, Jeffrey put forth the suggestion of:

[ An example of ] "related" that demonstrates how one could

"measure" or qualify related objects to the main objects using an
assertion?

2A) Does the last example which incorporates "measure", address
this in a useful manner?
2B) If not, would anyone familar with this be able to formulate a
statement and/or example that does?


Thank you,
Kraig

[finke...@gmail.com]

NSDL has started submitting paradata to sandbox. Some of our records can be seen here https://sandbox.learningregistry.org/slice?any_tags=paradata&from=2013-04-08.

I have looked at the Paradata in 20 minutes and the LR Paradata Spec 1.0 at
https://docs.google.com/document/d/1IrOYXd3S0FUwNozaEG5tM7Ki4_AZPrBn-pbyVUz-Bh0/edit and have two questions/concerns.

1) In the spec for collection object schema it specifies that we can bundle together multiple activities together in one document. My question here is consistency

In LRMI JSON microdata examples it shows resource data JSON as  -
resource_data:{items:[record1, record2]}

but per Paradata spec it says
resource_data:{"collection": {"totalItems": 2, "items": [record1, record2]}}

Is their a reason for this JSON difference? I just wasn't sure if this is desired or if these different formats were developed separately and a consistent format hasn't been agreed upon yet.

2) Also In the LR Paradata Spec 1.0, it shows an activity having a measure property which then has a float sub property(ie count, value) stays as a float in the JSON. We are using LRSignature written by Jim Klo, which during signing, normalizes the document and converts all float numbers and booleans into strings. So our float numbers during publishing are converted to strings. So should the spec specify the floats as strings instead or are we missing something? On a side note I would think that if floats are converted to strings, perhaps for consistency sake, integers in the activity should also be strings, ie scaleMin, scaleMax, count and sampleSize. Then a consumer of the documents can just convert all string values into floats.

example our data
"measure":{ "measureType": "star average",

       "value": 4.4,

        "scaleMin": 1,

        "scaleMax": 5,

                    "sampleSize": 2104},

during signing is converted to
"measure":{ "measureType": "star average",

       "value": "4.4",  <--- notice its a string not a float now

       "scaleMin": 1,

        "scaleMax": 5,

                    "sampleSize": 2104},


thanks
Dave Finke - NSDL Developer

[Jim Klo]

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 May 16, 2013, at 8:56 AM, <finke...@gmail.com>

 wrote:

NSDL has started submitting paradata to sandbox. Some of our records can be seen here https://sandbox.learningregistry.org/slice?any_tags=paradata&from=2013-04-08.

I have looked at the Paradata in 20 minutes and the LR Paradata Spec 1.0 at
https://docs.google.com/document/d/1IrOYXd3S0FUwNozaEG5tM7Ki4_AZPrBn-pbyVUz-Bh0/edit and have two questions/concerns.

1) In the spec for collection object schema it specifies that we can bundle together multiple activities together in one document. My question here is consistency

In LRMI JSON microdata examples it shows resource data JSON as  -
resource_data:{items:[record1, record2]}

This follows the HTML Microdata JSON convention: http://www.w3.org/TR/microdata/#json

but per Paradata spec it says
resource_data:{"collection": {"totalItems": 2, "items": [record1, record2]}}

This is following the LR Paradata spec: https://docs.google.com/document/d/1IrOYXd3S0FUwNozaEG5tM7Ki4_AZPrBn-pbyVUz-Bh0/edit#heading=h.c5h21psh9j5d

Is their a reason for this JSON difference? I just wasn't sure if this is desired or if these different formats were developed separately and a consistent format hasn't been agreed upon yet.

They are 2 different schema formats… like the differences between NSDL_DC and LOM… They are not 1 in the same.

2) Also In the LR Paradata Spec 1.0, it shows an activity having a measure property which then has a float sub property(ie count, value) stays as a float in the JSON. We are using LRSignature written by Jim Klo, which during signing, normalizes the document and converts all float numbers and booleans into strings. So our float numbers during publishing are converted to strings.

So should the spec specify the floats as strings instead or are we missing something? On a side note I would think that if floats are converted to strings, perhaps for consistency sake, integers in the activity should also be strings, ie scaleMin, scaleMax, count and sampleSize. Then a consumer of the documents can just convert all string values into floats.

Looks like you might have found a bug in my signing code… hmm… FWIW I might suggest we pull this conversation into a separate thread, as many are using the same code to perform signing, or modeled their implementation after this.  I'm not quite sure what to do here… at one point I had thought we had updated the signing spec to reflect this, but possibly not… a short discussion seems in order… It is known that the current spec has issues with hashing objects containing floating point values… but there had been initially no immediate need, as the suggestion had been made to encode numbers as strings which solves the problem. 

I'm open for proposals on alternate signature methods…  The key is coming up with a guaranteed canonical representation of the JSON object for digital signing.

This algorithm is done this way primarily because of the differences between systems and floating point precision, as floats are lossy in our binary world as they cross computing platforms…. Even CouchDB stores floats in a lossy manner.  Storing something like: { "foo": 1.1 }  ends up being stored as { "foo": 1.1000000000000000999 } and will get extracted from CouchDB that way…  

This is actually not a very uncommon practice - there are also dozens of solutions that folks have created over the years to deal with this… most basically are try to eventually conform to IEEE-754 double precision floating - but do it in different ways… There's an excellent writeup that was recently added to the CouchDB documentation  http://docs.couchdb.org/en/latest/json-structure.html#number-handling  that describes this problem amongst several different languages.

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