Reconcile Map data model with database model

[timothyfcook]

The data model for the maps needs to merge with the existing data model

I'll create a new .json template that reconciles the two and then @justinxreese (or his protege) can implement it.

The end result should be a more robust model that will serve both use cases.

[timothyfcook]

Note to remove short_name from the topic object

[timothyfcook]

Map data is now here: https://github.com/saxifrage/caac-map/blob/master/output/topics.json

[dmtroyer]

Oops, didn't mean to unassign you, Tim, was just trying to add myself.

[dmtroyer]

Spreadsheet from which the map JSON is derived:

https://docs.google.com/spreadsheets/d/10PurQxMbALCYNu7I3KfgUb2oMz4Uk5dLPZbTkdNb0ZM/edit?usp=sharing

[dmtroyer]

Here's a first stab at resolving the differences between the two models. My approach was to reference the map schema, and comment on where that field may already exist in the caac app, note if it needs to be created, or other idiosyncrasies.

Map Resource

• after_this -> not included, add id to opportunity
• age_range_end -> opportunity.max_age
• age_range_start -> opportunity.min_age
• badge_class_url -> DNE add to opportunity
• before_this -> DNE add id to opportunity
• difficulty_level -> opportunity_instance.difficulty
• digital_type -> DNE could this just be opportunity_instance.type? It is currently blank in the map model if it is not a digital opportunity. Seems like there is a hierarchy of types and sub-types here that could be done differently and needs to be flushed out.
• duration -> opportunity.duration
• has_badge -> DNE seems potentially unnecessary if there is a badge_class_url, but the whole badge model needs to be flushed out first
• id -> opportunity_instance.id
• image_url -> opportunity_instance.img
• instance_type -> opportunity_instance.type
• local_type -> DNE could this just be opportunity_instance.type? It is currently blank in the map model if it is not a local opportunity. Seems like there is a hierarchy of types and sub-types here that could be done differently.
• location_type -> this seems to be an enumeration, either digital or local, further thought is needed about this sort of categorazation
• org_description -> organizer.description
• org_name -> organizer.name
• org_name_lower_case -> DNE, could be dynamically created from organizer.name
• org_name_slug -> DNE, could be dynamically created from organizer.name unless it is being used as an id
• org_url -> organizer.url
• resource_description -> opportunity.description
• resource_name -> opportunity.name
• resource_name_lower_case -> DNE, could be dynamically created from opportunity.name
• resource_name_slug -> DNE, could be dynamically created from opportunity.name
• resource_url -> opportunity_instance.registration_url
• subtopic -> opportunity_instance.topic.child_of_topic
• subtopic_id -> DNE, how is this being used?
• subtopic_lower -> DNE, could be derived programmatically from opportunity_instance.topic
• topic -> opportunity_instance.topic
• topic_id -> DNE, necessary? unclear how/if this and subtopic_id are being used
• uid -> opportunity_instance.id

[dmtroyer]

I'm envisioning a JSON endpoint for the map which the python script will consume. In this case, we can make the necessary changes to the CAAC model, shore up consistency in naming in the map and go from there.

[timothyfcook]

@dmtroyer something else to consider... as part of the open badges work we have been tinkering with a data-model for pathways ...see that here: 1EdTech/openbadges-discussion#24

It could have some ramifications for how we create ours.

You should also read up on the badge spec: https://openbadgespec.org/

[dmtroyer]

awesome, I was just digging into some of the badge related changes.

I can imagine this will flush out more once we integrate badges into the app, but in looking at the awesome open badges spec I'm thinking we should be able to store the badge class id, which is a url that would link us to the all of the other badge goodies and would be better than us storing them ourselves.

It also strikes me that the has_badge field I'm seeing in the map projects json is superfluous. !opportunity.badge_class_url.nil? would give us the same thing.

[timothyfcook]

Sounds great on both fronts. Make it so!

[dmtroyer]

I'm kind of spinning my wheels on the following four fields that are included in caac-map's data model

• digital_type
• instance_type
• local_type
• location_type

It isn't clear to me how they are being used and what the difference is between them, and how to resolve that in the model.

I'm going to move on for now and come back to this, it could possibly benefit from its own issue.

[timothyfcook]

Sounds like we're killing instance_type and re-creating location_type as the primary resource_type that has various subtype's pulled from a pre-defined validated list of different resource formats, e.g. workshops, videos, films, courses, etc. subtype takes the place of digital_type and local_type

[dmtroyer]

resource_type and subtype applies to both opportunities and opportunity_instances with the instance overriding the class (opportunity) if it exists.