column names differ in pydracor and API

[DanilSko]

I wonder if this is a feature with some reason behind it, but I find it very inconvenient that column names in metadata retrieved by pydracor are different from those output by api directly. Pydracor returns metadata columns with snake_case names:
'num_of_segments', 'num_of_speakers', 'num_of_person_groups', 'word_count_sp', 'word_count_stage', 'average_degree', 'density', 'average_clustering', 'max_degree', 'num_connected_components', 'diameter', 'average_path_length'
while the API returns the same metadata columns with camelCase names:
'averageClustering', 'density', 'averagePathLength', 'averageDegree', 'diameter', 'maxDegree', 'numOfSpeakers', 'numOfSpeakersFemale', 'numOfSpeakersMale', 'numPersonGroups', 'numConnectedComponents', 'numOfSegments', 'wordCountText', 'wordCountSp', 'wordCountStage'

[cmil]

@DanilSko I think this is due to the different prevailing coding conventions in those environments. The DraCor API predominantly produces JSON, which - being the JavaScript Object Notation - prefers camel case, which is widely accepted in the Javascript community. The Python community on the other hand has a strong preference for "lower_case_with_underscores". In my opinion forcing any one of these conventions onto the other "coding culture" would cause more inconveniences than the lack of consistency in naming styles.

I would agree though that the wording for those meta data items should be the consistent. For instance it shouldn't be number_of_person_groups on one side and numPersGrps on the other. This kind of inconsistencies I would happily correct when they occur.

[lehkost]

Fully agree with @cmil – also, the PyDraCor hasn't been worked on in ages and is a bit out of step with recent API developments. Adjusting column names with API output should definitely be high up on the roadmap and easy to do.