Spec naming style

[will-moore]

When looking to add new keys to the spec I wonder how to name e.g. position_x I wonder what the naming style should be e.g.

• position_x
• positionX
• position-x
• positionx

Looking at the current spec, we have all of these styles there already, reflecting the origin of various terms (mea culpa):

• image-label
• defaultT - Rendering definition (omero). to be replaced by rendering spec?
• maximumfieldcount - HCS, to be replace by Collections spec
• field_count - Also HCS.

So, which of these do we prefer? Python style, Java style or something else?

[constantinpape]

We should absolutely have a consistent naming style. I would personally vote for snake case (python style) but I don't have a strong opinion and camel case (java style) would also be fine with me.

[glyg]

I agree with @constantinpape (1. snake case, 2. camelCase) with a rather strong rejection of the "postion-x" just because I know I'll have to parse out the dash sign at some point and I'm lazy, and a very strong rejection of "positionx" because it will be confusing with e.g. the curvilinear coordinate "s"

[joshmoore]

Similar to the "dashes don't work great in programming languages", I'd add that casing isn't always that clear with URLs. Since I expect these identifiers will eventually get used in such contexts, I'd favor position_x over positionX.

[jburel]

If we wish to follow the style in place in schema.org, positionX should be used

[jburel]

From comment on ome/omero-cli-render#55

My comment is more general that this specific issue. The suggestion of following schema.org is coming from the fact that others efforts e.g. bioschema.org, ro-crate follow that convention so it might make more sense to follow similar rule instead of the snake_case convention
especially if we start interacting. I can see for example in a zarr file
the original data, the segmented data, and the workflow used to generated the segmented data.
The workflow will/might follow the ro-crate convention if published on workflowhub for example so the user won't spend time converting the json, this means that will lead to either multiple conventions in the file or metadata not being added at all.

[jburel]

see also https://www.ebi.ac.uk/spot/oxo/docs/api (ontologies related)

[constantinpape]

Given ongoing PRs in #57 etc. it would be good to come to a decision here. Given the usage of camelCase in schema.org it seems like this would be the prefered choice.
Any objections against that?

[joshmoore]

@glyg had the strongest objection in #54 (comment). I'm personally tend towards underscores (i.e. more PEP8)

[constantinpape]

I read #54 (comment) as being fine with both camel or snake case, just objecting (rightfully in my opinion) to position-x or positionx.

[joshmoore]

Ah, I see. I misread.

[glyg]

Hi, I feel @constantinpape argument for camel case as being already in use at schema.org wins - my python tropism maybe clouds my judgement :) - I guess you can always work around the lowercase url issue?

[will-moore]

I don't know if we're actually going to use schema.org, but it seems that many schemas and data-models tend to use camelCase so in the interests of consistency I think that makes the most sense.
I think @joshmoore is OK with camelCase too?
So hopefully that's looking like a new consensus...

[will-moore]

Opened a PR at #70 to add the camelCase naming convention to the spec.