You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Basic fields like YMM are required. Optional fields are allowed like engine, doors, windshield size, anything the user wants.
Uploads go into a queue, separate from approved data.
There is "views" when viewing approved/uploaded data. Default view = YMM. If the user views "YMME" (engine)... then they see more records. If there's Honda\Civic\2000 that has 5 engines, the default view only shows 1 vehicle, but a custom view showing the engine field would show 5 vehicles. Whatever is distinct.
If a custom view shows columns we don't have for a specific vehicle, due to sparsity, we simply show "null" for now unless we come up with a better idea.
If users upload data missing a required column like the "make", we still take it in but show "null" for the make. The difference here is that data will not merge in until its completed.
As implied, uploaded data goes through stages. Uploaded, Merging, and voting. Uploading is the raw data. Merging data reconciles it (fill in missing values) [ Note to self: is merging a necessary step? Maybe only for "crappy" data, good data skips that step. KISS> or maybe merging is something that just happens without the user knowing, so they don't vote on data we already have.) Final step is voting, a user can vote it up or down. No ability to comment yet.
After data is voted on, I don't know what happens. I'll figure that out later. I'll build this part first. Maybe itll become approved data automatically somehow, or maybe I'll have to employ workers to moderate it, etc... doesn't matter as the first stages are invariant in this design, so build that first.
The text was updated successfully, but these errors were encountered:
Users will upload data in varying schemas.
Basic fields like YMM are required. Optional fields are allowed like engine, doors, windshield size, anything the user wants.
Uploads go into a queue, separate from approved data.
There is "views" when viewing approved/uploaded data. Default view = YMM. If the user views "YMME" (engine)... then they see more records. If there's Honda\Civic\2000 that has 5 engines, the default view only shows 1 vehicle, but a custom view showing the engine field would show 5 vehicles. Whatever is distinct.
If a custom view shows columns we don't have for a specific vehicle, due to sparsity, we simply show "null" for now unless we come up with a better idea.
If users upload data missing a required column like the "make", we still take it in but show "null" for the make. The difference here is that data will not merge in until its completed.
As implied, uploaded data goes through stages. Uploaded, Merging, and voting. Uploading is the raw data. Merging data reconciles it (fill in missing values) [ Note to self: is merging a necessary step? Maybe only for "crappy" data, good data skips that step. KISS> or maybe merging is something that just happens without the user knowing, so they don't vote on data we already have.) Final step is voting, a user can vote it up or down. No ability to comment yet.
After data is voted on, I don't know what happens. I'll figure that out later. I'll build this part first. Maybe itll become approved data automatically somehow, or maybe I'll have to employ workers to moderate it, etc... doesn't matter as the first stages are invariant in this design, so build that first.
The text was updated successfully, but these errors were encountered: