search

ODM2 / YODA-File

The YAML Observation Data Archive & exchange (YODA) File Format
BSD 3-Clause "New" or "Revised" License
4 stars 0 forks source link

Sites, specimens, and timeseriesresults should not be anchors #8

Closed SRGDamia1 closed 9 years ago

SRGDamia1 commented 9 years ago

These tables are just extension tables and shouldn't have any sort of anchor. They shouldn't be referred to on their own. So in the column definitions block, the results should be the ResultID##, not the TimeSeriesResultID##. I don't think it makes much practical difference for the YAML itself, but it makes it a bit off of ODM2.

horsburgh commented 9 years ago

This is probably true of Sites because the Site anchors are not referenced by anything else. I think I added them for consistency. I was thinking - just give everything an anchor. The same may be true of Specimens. I would be OK with either convention:

  1. Give every entity instance an anchor; OR
  2. Only give things anchors if they are referenced somewhere else.

The anchors for TimeSeriesResults are actually used. TimeSeriesResults are not the same as Results and need to have separate anchors. The Result anchors are referenced by TimeSeriesResults, and the TimeSeriesResultAnchors are referenced by the column definitions in the data block.

SRGDamia1 commented 9 years ago

In your example you did use the TimeSeriesResults anchors, but they really should not be used. You should refer directly all the way back to the Results anchor. That's what would happen in ODM2 because the TimeSeriesResults table doesn't actually have any primary key that can be referred to. I think for consistency with ODM2 we should have anchors be equivalent with primary keys. So tables that have their own primary keys have anchors and those that don't, don't. The only exception is if the table's primary key is "BridgeID," those tables also should not have anchors.

horsburgh commented 9 years ago

The TimeSeriesResults table does have a primary key in ODM2 (ResultID). It's primary key shares the same name as the primary key of the Results table because TimeSeriesResults is a specialization of Results. But, since there are different attributes in both tables and they are separate tables in ODM2, they need to appear separately in the YAML file with separate anchors. Stephanie and Jacob have made it clear that this is needed (or at lease makes it WAY easier) to parse the files into the ODM2 API objects. You can't use the same anchor to reference two different objects in YAML.

SRGDamia1 commented 9 years ago

Ok. I think I'm confused about the structure in ODM2. I thought the "ResultID" acting as a primary key in the TimeSeriesResults table was actually itself a foreign key and identical to the "ResultID" in the result table.

Either way, though, because there aren't really primary keys in the YAML, if adding an anchor to the TimeSeriesResults table makes parsing easier, we can do it.

horsburgh commented 9 years ago

The relationship between the Results entity and the TimeSeriesResults entity is effectively one-to-one. So, the ResultID in TimeSeriesResults acts as both a primary key and a foreign key.

Yes - add the anchor to TimeSeriesResults in the YODA files.

SRGDamia1 commented 9 years ago

I did do this some ways back. Just closing issue to get it out of the way.