OCA File does not accept .'s in attribute names anymore

[carlyh-micb]

Tested here: https://repository.oca.argo.colossi.network/#/Public%20API/post_oca_bundles

Doesn't work:

ADD ATTRIBUTE "d.name"=Text i=Text passed=Boolean
ADD META en PROPS name="Entrance credential" description="Entrance credential"

Doesn't work

ADD ATTRIBUTE d.name=Text i=Text passed=Boolean
ADD META en PROPS name="Entrance credential" description="Entrance credential"

Does work:

ADD ATTRIBUTE d_name=Text i=Text passed=Boolean
ADD META en PROPS name="Entrance credential" description="Entrance credential"

Many times attribute names are listed with a . in the name. This is common in research, and the widely used statistics program R has .'s in attribute names. Not all languages and programs ban .'s in attribute names and to be inclusive for describing data OCA should continue to allow .'s in attribute names. It would be up to specific ecosystems to establish what is acceptable for their use cases.

Here is an example set of data headers coming off of a research instrument. As OCA File is currently implemented by OCA-repo this data could not be described by OCA by referencing these specific attribute names.

Feature.ID	Experiment...Range..original.values.	Experiment...IQR..original.values.	Experiment...Difference..original.values.	Experiment...Fold.Change..original.values.	Experiment...Range..transformed.values.	Experiment...IQR..transformed.values.

Currently the OCA specification allows .'s, and it is allowed when using the Excel Template file to generate OCA schema bundles.

[swcurran]

My $0.02CDN on this. The spec currently has no opinion on the presence or absence of characters in the attribute name, and it should (mostly) stay that way. The spec should definitely NOT say that certain characters are invalid in an attribute name, as invariably, someone will have a reason to have the invalid character in the name.

We intended to have in a flat list of attributes embedded characters such that the attribute name represents a path and the attribute in a hierarchy, such as with JSONPath (e.g., address.street, address.city). For that, the “.” could be used as the JSONPath element, or a “/“ as the Swiss are using. We think it would be good to put that in the OCA spec that the presence of such characters MAY indicate a hierarchy. But the spec does not have to include even that. It just can’t preclude those characters.

[blelump]

@carlyh-micb fixed via oca-bin 0.5.3.

@swcurran, we merely extended the grammar at THCLab/oca-rs@27ebc85 to support dot characters. If a use case needs paths, it's up to that use case; therefore, separator characters and their meaning are out of scope in the OCA spec.