Inconsistent tag/class inference about brick

[gtfierro]

Distinguishing two classes with tags is absolutely possible, but it requires making sure the tags are coherently applied.

If you look at the definition of Run_Status, it is defined as being equivalent to two tags (https://github.com/BrickSchema/Brick/blob/master/status.py#L229), and thus it inherits the super class Start_Stop_Status. This should be better articulated so that each subtree of tags is unique, but it is far from a fundamental issue with the structure. We could probably remedy some of the subclass relationships; the existing hierarchy is carried forward from Brick v1 I believe, which explains the inconsistencies.

Its too bad that the inference/test results are private google drive documents. Can you put them up as Github gists instead so they are easier to work with?

Also, it would be good if we can isolate the specific classes and tags that are causing a mismatch between the expected parent classes and the inferred parent classes

[jbkoh]

I didn't use Gist because the TTL file was too large. The browser hangs. The JSON file turns out to be fine so I edited the link above. (https://gist.github.com/jbkoh/438a58d2cfb250654f2b6e15431a8a55)

I understand the structure itself has no problem with the inconsistency but the human authors are, and the testing framework should help them.

The V1 hierarchy did not assume tags subsumptions and that's why it was fine (of course there should have been obvious bugs anyway.)

I think we have to manually go through the 177 classes before we release the version.