The exerciseData property

[smnmyr]

This field expresses which types of information can be obtained from the object. This should follow a common vocabulary, and the relationship to the object should be made more obvious... would renaming the property help? ("exerciseDataContainedInObject"... :-))

[dret]

the first attempt at #1 is just a proposal. it is following the model of https://github.com/dret/GeoJSON-X which also just uses "well-known keywords". as usual on the web, this could be a fixed set of keywords, a registry of some sorts (i.e., an evolving vocabulary), or an open model with URIs as identifiers. it also could combine these aspects a la RFC 5988, so that there's a registry, as well as openness via URIs.

[dret]

after a bit of reorg, https://github.com/dret/exercise/tree/master/EDF now has a list of "well-known" concepts and that list will grow once we start playing around with more services and/or more sensors. the idea is that this page for now serves as "the registry", and that EDF follows the RFC 5988 rule of either using simply keywords from that registry, or URIs in case of non-registered extensions.

[dret]

as an interesting data point, i found this list of concepts for CSV when looking around for how to best our exercise data in CSV: http://www.gpsbabel.org/htmldoc-1.5.2/fmt_unicsv.html

[smnmyr]

I suggest moving the exerciseData property into the object - if there is no object, there is little sense in describing the data it contains. Do you see any issues with that?

[dret]

sounds reasonable to me.