# Commit to a common syntax for accessing additional index mapping information on axes
**URL:** https://discourse.julialang.org/t/commit-to-a-common-syntax-for-accessing-additional-index-mapping-information-on-axes/84988
**Category:** Data
**Created:** [July 29, 2022, 4:38pm UTC](https://discourse.julialang.org/t/commit-to-a-common-syntax-for-accessing-additional-index-mapping-information-on-axes/84988 "2022-07-29T16:38:47Z")
**Posts on this page:** 20
**Page:** 2
### Author:  [@aplavin](https://discourse.julialang.org/u/aplavin)
#### Post date: [August 1, 2022, 2:27pm UTC](https://discourse.julialang.org/t/commit-to-a-common-syntax-for-accessing-additional-index-mapping-information-on-axes/84988/21 "2022-08-01T14:27:54Z")
Why can’t it be the same function?
Named dimensions → return NamedTuple
Unnamed dimensions → return Tuple
---
### Author:  [@Zach\_Christensen](https://discourse.julialang.org/u/Zach_Christensen)
#### Post date: [August 1, 2022, 3:31pm UTC](https://discourse.julialang.org/t/commit-to-a-common-syntax-for-accessing-additional-index-mapping-information-on-axes/84988/22 "2022-08-01T15:31:59Z")
It can’t ever be a `NamedTuple` unless we decide that all dimension names are unique, including the representation for unnamed dimensions. If we return some type that acts like a `NamedTuple` but isn’t, that makes it difficult to pass around and use in a meaningful way because we often perform recursive functions that require dispatching on the number of fields in the tuple and the type in the first position.
This doesn’t mean we can’t ever do something like this in the future, but I’d rather not build it into the design right now if we still don’t even now what this named collection would look like.
---
### Author:  [@aplavin](https://discourse.julialang.org/u/aplavin)
#### Post date: [August 1, 2022, 3:56pm UTC](https://discourse.julialang.org/t/commit-to-a-common-syntax-for-accessing-additional-index-mapping-information-on-axes/84988/23 "2022-08-01T15:56:58Z")
Ah, now I see: you must be talking about mixing named and unnamed dimensions? I didn’t think of that before at all. If either all dims are named, or all are unnamed, there’s no issue, right?
Is it even possible to unambiguously mix named and unnamed in the same array - any examples in the wild?
---
### Author:  [@Zach\_Christensen](https://discourse.julialang.org/u/Zach_Christensen)
#### Post date: [August 1, 2022, 4:07pm UTC](https://discourse.julialang.org/t/commit-to-a-common-syntax-for-accessing-additional-index-mapping-information-on-axes/84988/24 "2022-08-01T16:07:08Z")
[GitHub - mcabbott/NamedPlus.jl: 🏴☠️](https://github.com/mcabbott/NamedPlus.jl) is probably the most extensive experimentation with keeping names with their corresponding stuff.
I’m not saying that we can’t handle returning something that’s named in the future. I just don’t think there’s a clear path forward for that now and it shouldn’t be built into a very basic level for extracting this data unless we can ensure it won’t overcomplicate other things.
---
### Author:  [@jd-foster](https://discourse.julialang.org/u/jd-foster)
#### Post date: [August 2, 2022, 7:03am UTC](https://discourse.julialang.org/t/commit-to-a-common-syntax-for-accessing-additional-index-mapping-information-on-axes/84988/25 "2022-08-02T07:03:24Z")
Another data point here: @oxinabox 's [NamedDims](https://github.com/invenia/NamedDims.jl)
---
### Author:  [@Zach\_Christensen](https://discourse.julialang.org/u/Zach_Christensen)
#### Post date: [August 2, 2022, 9:07am UTC](https://discourse.julialang.org/t/commit-to-a-common-syntax-for-accessing-additional-index-mapping-information-on-axes/84988/26 "2022-08-02T09:07:52Z")
NamedDims only supports dimension names. It doesn’t provide anything for the length of the entire dimension. AxisKeys uses NamedDims and adds this feature
---
### Author:  [@oxinabox](https://discourse.julialang.org/u/oxinabox)
#### Post date: [August 2, 2022, 9:35pm UTC](https://discourse.julialang.org/t/commit-to-a-common-syntax-for-accessing-additional-index-mapping-information-on-axes/84988/27 "2022-08-02T21:35:32Z")
Is this a job for:
> **[GitHub - ararslan/FrankenTuples.jl: Part Tuple, part NamedTuple... it's alive!](https://github.com/ararslan/FrankenTuples.jl)**
>
> Part Tuple, part NamedTuple... it's alive! Contribute to ararslan/FrankenTuples.jl development by creating an account on GitHub.
---
### Author:  [@Zach\_Christensen](https://discourse.julialang.org/u/Zach_Christensen)
#### Post date: [August 2, 2022, 11:22pm UTC](https://discourse.julialang.org/t/commit-to-a-common-syntax-for-accessing-additional-index-mapping-information-on-axes/84988/28 "2022-08-02T23:22:34Z")
I don’t think FrankenTuples.jl would work for this. It has the unnamed and named components seperately, so dimensions with the names `(:x, :_, :y)` couldn’t be represented here.
If you want both dimension names and these keys/labels then you just do `dimnames(data)` and `newsyntax(data)`. If there’s a perfect solution out there I’m open to it, but I don’t think there’s much benefit to complicating this new method just to carry around extra information by default.
---
### Author:  [@Raf](https://discourse.julialang.org/u/Raf)
#### Post date: [August 3, 2022, 11:26am UTC](https://discourse.julialang.org/t/commit-to-a-common-syntax-for-accessing-additional-index-mapping-information-on-axes/84988/29 "2022-08-03T11:26:27Z")
@Zach_Christensen I’m warming to `axislookup` or `axislabels`.
`axislookup` captures the fact we usually use these values to look up an index for the axis, and `axislabels` that they are the printed/plotted labels. But `axislabels` can also be interpreted to mean the name of the axis, like `X` and `Y`.
I think `axislookup` or `lookup` are the least overloaded in base and the broader ecosystem.
(or pluralised `axislookups`)
---
### Author:  [@aplavin](https://discourse.julialang.org/u/aplavin)
#### Post date: [August 3, 2022, 12:56pm UTC](https://discourse.julialang.org/t/commit-to-a-common-syntax-for-accessing-additional-index-mapping-information-on-axes/84988/30 "2022-08-03T12:56:07Z")
Indeed, there are two main uses for these axis-associated values: lookup and display labels. Not sure if one of these usages is much more common than the other, both seem pretty frequent.
Both `lookup` and `labels` strongly focus on one of those usecases. These values are not really “lookup” if only used to determine plot ticks, and not really “labels” if only used for selections like `arr(time = 0..1)`.
Maybe, it’s actually not bad to use more general names, even if they are somewhat overloaded? For example, `axisvalues` is also quite nice, but only mentioned once in the first post. `axiskeys/axisvalues` don’t carry that strong focus on specific usages of these values. Also, they intuitively fit with a common approach of indexing by key/value: that can be written `arr[time=Value(1)]` if `axisvalues` if used, or `arr[time=Key(1)]` if `axiskeys`.
---
### Author:  [@Zach\_Christensen](https://discourse.julialang.org/u/Zach_Christensen)
#### Post date: [August 3, 2022, 2:33pm UTC](https://discourse.julialang.org/t/commit-to-a-common-syntax-for-accessing-additional-index-mapping-information-on-axes/84988/31 "2022-08-03T14:33:41Z")
Values has the same problem as keys. It already has a meaning in Julia. It also doesn’t provide much description about what is being returned.
---
### Author:  [@Zach\_Christensen](https://discourse.julialang.org/u/Zach_Christensen)
#### Post date: [August 3, 2022, 4:23pm UTC](https://discourse.julialang.org/t/commit-to-a-common-syntax-for-accessing-additional-index-mapping-information-on-axes/84988/32 "2022-08-03T16:23:35Z")
`axislookups` sounds a bit awkward to me but in the end I’m open to any reasonable suggestion we can all live with. (Reasonable meaning not intentionally ridiculous)
---
### Author:  [@Zach\_Christensen](https://discourse.julialang.org/u/Zach_Christensen)
#### Post date: [August 3, 2022, 6:00pm UTC](https://discourse.julialang.org/t/commit-to-a-common-syntax-for-accessing-additional-index-mapping-information-on-axes/84988/33 "2022-08-03T18:00:49Z")
Time for a quick update:
@yha and @jar1 pointed out that the set of criteria I made at first may be overly restrictive/confusing. I think @aplavin did a good job of conceptualizing this as collections along an axis that can be used to lookup indices or label indices for plots and such. I think that helps differentiate from something generic along the axis, such as the discussion of `colmetadata`.
There’s also been discussion of attaching dimension names in the form of a `NamedTuple` (or some other type that would support the return of `dimnames`). There are certain complexities associated with doing so (that don’t permit use of `NamedTuple`) and not all data will have meaningful values from `dimnames` anyway, so it’s better to return a simple `Tuple` for what we’re currently discussing, permitting some other method to combine the two later on as needed.
Feedback on names:
1. `axiskeys`
1. (➕) already used by `AxisKeys.jl so some people are used to it (most votes so far)
2. (➕) semantically related to the common use case of “keys”
3. (➖) “keys” already has a meaning for arrays and an axis is `AbstractUnitRange{Int} <: AbstractVector{Int}`. So it’s a bit odd that `keys(axes(data, dim))` would not mean the same thing.
2. `axisvalues`
1. (➕) already used by AxisArrays.jl so some people are used to it
2. (➖) `axisvalues(data, dim) != values(axes(data, dim))`.
3. `axislabels`
1. (➕) meaning of labels is fairly compatible with use cases (keys ≈ labels; axis labels on plots)
2. (➖) potentially too generic, making it awkward if we end up wanting `labels(data)` for something unrelated.
4. `axislookups`
- (➕) same semantic benefit as 1.2
- (➖) potentially too descriptive, sounding distinct from use as axis labels for plots/images/etc.
5. `axisnames`
- (➕) R uses `dimnames` for similar functionality
- (➖) “names” is overly specific
At the very least, we can probably eliminate `axisnames` as a candidate now.
---
### Author:  [@nalimilan](https://discourse.julialang.org/u/nalimilan)
#### Post date: [August 3, 2022, 9:01pm UTC](https://discourse.julialang.org/t/commit-to-a-common-syntax-for-accessing-additional-index-mapping-information-on-axes/84988/34 "2022-08-03T21:01:47Z")
`axiskeys` and `axisvalues` are problematic IMO for the reasons you note.
`axislabels` sounds better than `axislookups` to me, as the series “indices”/“keys”/“labels” sounds more consistent than “indices”/“keys”/“lookups”. “Lookup” is an action, contrary to all other terms. And the plural “lookups” is weird.
Another option would be something like `axistags`. But I don’t think “tag” is used anywhere else with this meaning.
---
### Author:  [@Zach\_Christensen](https://discourse.julialang.org/u/Zach_Christensen)
#### Post date: [August 3, 2022, 9:53pm UTC](https://discourse.julialang.org/t/commit-to-a-common-syntax-for-accessing-additional-index-mapping-information-on-axes/84988/35 "2022-08-03T21:53:09Z")
`axislabels` is growing on me. I think tag and token can have different meanings in code than this.
---
### Author:  [@jar1](https://discourse.julialang.org/u/jar1)
#### Post date: [August 3, 2022, 10:13pm UTC](https://discourse.julialang.org/t/commit-to-a-common-syntax-for-accessing-additional-index-mapping-information-on-axes/84988/36 "2022-08-03T22:13:21Z")
`axisids` might work.
---
### Author:  [@Zach\_Christensen](https://discourse.julialang.org/u/Zach_Christensen)
#### Post date: [August 4, 2022, 1:29pm UTC](https://discourse.julialang.org/t/commit-to-a-common-syntax-for-accessing-additional-index-mapping-information-on-axes/84988/37 "2022-08-04T13:29:55Z")
Is “identifiers” a more apt description that “labels”? If so, would `axisidentifiers` be more clear?
“ID” is somewhat in use already for things like `Base.objectid`, which relates to `IdDict` and `IdSet`.
---
### Author:  [@Zach\_Christensen](https://discourse.julialang.org/u/Zach_Christensen)
#### Post date: [August 6, 2022, 2:26am UTC](https://discourse.julialang.org/t/commit-to-a-common-syntax-for-accessing-additional-index-mapping-information-on-axes/84988/38 "2022-08-06T02:26:18Z")
I updated the original `axes_keys` [PR](https://github.com/JuliaArrays/ArrayInterface.jl/pull/328) to use `axislabels`. This doesn’t mean the syntax is set in stone and the documentation still needs to be fledged out with examples, but I thought it might be good to show what this would look like.
---
### Author:  [@Zach\_Christensen](https://discourse.julialang.org/u/Zach_Christensen)
#### Post date: [August 8, 2022, 11:57am UTC](https://discourse.julialang.org/t/commit-to-a-common-syntax-for-accessing-additional-index-mapping-information-on-axes/84988/39 "2022-08-08T11:57:08Z")
It looks like we had 5 for `axiskeys`, 2 for `labels`, 2 for “other” and 1 for `name`. I think some opinions may have changed throughout the conversion though. From the discussion it seems like those who wanted `axiskeys` would be fine with something similar like `axislabels`, which would resolve some of the overlap with `keys`.
Would anyone object to moving forward with `axislabels`?
---
### Author:  [@aplavin](https://discourse.julialang.org/u/aplavin)
#### Post date: [August 12, 2022, 12:59am UTC](https://discourse.julialang.org/t/commit-to-a-common-syntax-for-accessing-additional-index-mapping-information-on-axes/84988/40 "2022-08-12T00:59:04Z")
Xarray uses the “coords” term that sounds both generic enough and not overloaded much in the julia ecosystem. So, maybe axiscoords, dimcoords, or something similar would be best?
[Previous page](https://discourse.julialang.org/t/commit-to-a-common-syntax-for-accessing-additional-index-mapping-information-on-axes/84988.md?page=1)
[Next page](https://discourse.julialang.org/t/commit-to-a-common-syntax-for-accessing-additional-index-mapping-information-on-axes/84988.md?page=3)