GDocs data structure

[dhornbein]

Current column headers for our spreadsheets need to be discussed, they are:

• id - an id for each row, it doesn't make sense because people would have to input them manually
• name - the scientific name of the plant or animal, the idea here is that this name will match across any pClock out there. It's the unique identifier of any entry.
• common name - what the common person calls the plant/animal
• category - a list of categories, ideally the pClock could group common species
• event start - when a single phenological event starts
• event end - when a single phenological event ends
• description - text description of the event
• color- the HEX color of the event

We should try and nail this all down for the MVP. Here's the data structure as it currently stands:

{
"categories": ["cat1", "cat2", "cat3"],
"category": "perennial",
"color": "ffff00",
"description": "",
"events": [
  {
    "start":"1/1/2014",
    "end":"1/1/2015",
  }
],
"id": "",
"name": "Achillea filipendulina ‘Parker’s Variety’"
}

The key thing (which isn't supported right now) is that each specie of animal/plant supports multiple events which should be rendered inline (perhaps, see: #12).

Potential additional column headers

mutualistic relationships - what plants work with this one
Reference - link to data about the plant/animal

How do you feel about this data structure, what makes sense, what doesn't, what should be added or removed or changed?

[dhornbein]

I've created a version 2 of the spreadsheet see it here.

Columns added:

• location some form of location data, ideally it would accept address, zip code, state, region, or lon/lat
• event name this allows each row (which represents an event) to have a unique name
  Changed:
  -name to specie name to make it clear what name to put here
  Removed:
• id don't see a need for an id in the spreadsheet

Color needs to move into the events array...

{
"categories": ["cat1", "cat2", "cat3"],
"category": "perennial",
"description": "",
"location":"11216",
"events": [
  {
    "event name":"blooming",
    "start":"1/1/2014",
    "end":"1/1/2015",
    "color": "ffff00",
  }
],
"specie name": "Achillea filipendulina ‘Parker’s Variety’"
}

[thiagodemellobueno]

Event names probably don’t need to be unique.

On Apr 13, 2014, at 6:54 PM, Drew notifications@github.com wrote:

I've created a version 2 of the spreadsheet see it here.

Columns added:

location some form of location data, ideally it would accept address, zip code, state, region, or lon/lat
event name this allows each row (which represents an event) to have a unique name Changed: -name to specie name to make it clear what name to put here Removed:
id don't see a need for an id in the spreadsheet
Color needs to move into the events array...

{
"categories": ["cat1", "cat2", "cat3"],
"category": "perennial",
"description": "",
"location":"11216",
"events": [
{
"event name":"blooming",
"start":"1/1/2014",
"end":"1/1/2015",
"color": "ffff00",
}
],
"specie name": "Achillea filipendulina ‘Parker’s Variety’"
}
—
Reply to this email directly or view it on GitHub.

[thiagodemellobueno]

Can you elaborate on why you changed the data model so drastically?

It's important for the app to work for us to decide whether each entry is a species, or a phenophase... There are probably arguments for both.

But my view is we are plotting rings, representing species, and then arcs in the rings representing phenophase events... it makes sense then that the dataset then, be grouped by species.

It seems like we had a working model before, but maybe I'm missing some use case that precipitated this?

Also note that if you change the data model, you need to change the data parsing method (the one that parses the GDoc) so that the app still knows how to work witht he data (or refactor the app).

I would certainly hold off filing bugs related to the changing of the data model until after this issue is resolved, since its pretty natural that things would break when you change the data structure.

[dhornbein]

agreed, I'll write up more detailed use cases so we can find consensus before moving forward with any changes.