{"action":"created","issue":{"url":"https://api.github.com/repos/SignalK/specification/issues/304","repository_url":"https://api.github.com/repos/SignalK/specification","labels_url":"https://api.github.com/repos/SignalK/specification/issues/304/labels{/name}","comments_url":"https://api.github.com/repos/SignalK/specification/issues/304/comments","events_url":"https://api.github.com/repos/SignalK/specification/issues/304/events","html_url":"https://github.com/SignalK/specification/issues/304","id":194509099,"number":304,"title":"Key hierarchy causes confusion","user":{"login":"jboynes","id":1704738,"avatar_url":"https://avatars.githubusercontent.com/u/1704738?v=3","gravatar_id":"","url":"https://api.github.com/users/jboynes","html_url":"https://github.com/jboynes","followers_url":"https://api.github.com/users/jboynes/followers","following_url":"https://api.github.com/users/jboynes/following{/other_user}","gists_url":"https://api.github.com/users/jboynes/gists{/gist_id}","starred_url":"https://api.github.com/users/jboynes/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/jboynes/subscriptions","organizations_url":"https://api.github.com/users/jboynes/orgs","repos_url":"https://api.github.com/users/jboynes/repos","events_url":"https://api.github.com/users/jboynes/events{/privacy}","received_events_url":"https://api.github.com/users/jboynes/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":4,"created_at":"2016-12-09T04:06:02Z","updated_at":"2016-12-10T17:40:10Z","closed_at":null,"body":"Observing the discussions on electrical, propulsion and now environment, trying to determine an appropriate hierarchy for key names seems fraught and arbitrary. In the recent discussion on temperatures, there are names derived from the N2K spec source type, but also a generic catch-all `environment.temperature.<sourceID>` (which also needs to include an `<instanceID>`)\r\n\r\nWhat value do we get from trying to figure out this hierarchy? Especially when combined with the idea of a manifest as proposed in [RFC0001](https://github.com/SignalK/specification/issues/264).\r\n\r\nWe could dispense with the hierarchy entirely, and instead:\r\n- include the devices, with source and instance ids in the manifest\r\n- label the device/source/instance with a human-readable name (e.g. \"Sea Temp\" or \"Aft Cabin Temp\")\r\n- derive a unique but opaque id for the value e.g. from the device/source/instance components\r\n- use that as the key name in the vessel's context\r\n\r\nA display client would define its panel in terms of the opaque ids, can get the display label from the manifest and the value from the vessel context by id.\r\n\r\nFor example, on a Mareton TMP100 device, channel 2 may be measuring temperature in the fore cabin and channel 3 in the aft cabin. These two sensors may be given ids `tmp100-1234-2` and `tmp100-1234-3` respectively. In the manifest they would be defined as instances 1 and 2 of the `Inside Air` source type and be given the 'Fore' and 'Aft' labels. When a PGN was received, the server would map (tmp100, Inside Air 1) to `tmp100-1234-2` using the manifest and update the `tmp100-1234-2` in the `vessel.{vesselId}` context. A display client using the REST interface would see a reference to `tmp100-1234-2` in the display panel configuration, retrieve the label from the manifest entry for that key in order to display the \"Fore Cabin\" label and subscribe to the `vessel.{vesselId}.tmp100-1234-2` path to receive the updates for the temperature value.\r\n\r\nBy flattening the data we avoid all the problems of trying to figure out the right place in the hierarchy for values and make the model extensible for additional data. We need all the plumbing anyway to deal with undefined entries like `environment.temperature.<sourceID>` and to assign human-readable labels to instance ids."},"comment":{"url":"https://api.github.com/repos/SignalK/specification/issues/comments/266225191","html_url":"https://github.com/SignalK/specification/issues/304#issuecomment-266225191","issue_url":"https://api.github.com/repos/SignalK/specification/issues/304","id":266225191,"user":{"login":"sumps","id":10165637,"avatar_url":"https://avatars.githubusercontent.com/u/10165637?v=3","gravatar_id":"","url":"https://api.github.com/users/sumps","html_url":"https://github.com/sumps","followers_url":"https://api.github.com/users/sumps/followers","following_url":"https://api.github.com/users/sumps/following{/other_user}","gists_url":"https://api.github.com/users/sumps/gists{/gist_id}","starred_url":"https://api.github.com/users/sumps/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/sumps/subscriptions","organizations_url":"https://api.github.com/users/sumps/orgs","repos_url":"https://api.github.com/users/sumps/repos","events_url":"https://api.github.com/users/sumps/events{/privacy}","received_events_url":"https://api.github.com/users/sumps/received_events","type":"User","site_admin":false},"created_at":"2016-12-10T17:40:10Z","updated_at":"2016-12-10T17:40:10Z","body":"We have a system at the moment that works with minimal human input and that is a very important point and was one of the original key goals that we successfully achieved.\r\n\r\nWhat I do not see in all of these discussions is how this new hierarchy is automatically populated. Annotations, manifests, human readable labels, etc. How are these automatically setup with no human intervention ? If we are expecting Signal K users to spend hours setting all of this stuff up manually then take up is going to be very low. "}}
{"actor":{"display_login":"sumps"}}