Support for multiple types (e.g marinas, buoys, etc)

[fabdrol]

Signal K should support objects beyond vessels. Think of marinas, buoys, virtual objects etc. each type of object can have it's own data groups as well as groups other types have.

Things to consider:

• DRY-ness in Schema: we should avoid duplicate data URIs. An option would be to extend the definitions file.
• Categories: there has been some discussion about categories: grouping types by category (mobile, static, virtual, etc) instead of just having all under root.
• Naming

[fabdrol]

Related to #74

[rob42]

The logical topmost node is org.signalk. So we could have org.signalk.vessels or we might be wise to have an additional layer, eg org.signalk.marine.vessels. That would allow better options for future classes like vehicles air etc

As far as non-vessel AIS goes, whatever we call it we need a node at the same level as vessels. That means we need the org.signalk... too. So my suggestion org.signalk.marine.shore

[fabdrol]

@rob42 why the org.signalk? Is that just namespace or would you like to see that in the schemas? I think <category>.<type> (i.e. org.signalk.marine.vessels) makes sense. That way we can differentiate between various types as vessels without polluting the vessel tree itself. E.g. recreational.vessel, sar.vessel (& sar.helicopter), military.vessel etc

[rob42]

Yes org.signalk is root namespace. But theoretically it should be possible to query for org.signalk.* and get the whole world... We probably need some basic rules for implicitly deriving namespaces. Not really a problem I think - the REST api is good with /signalk/api/v1/shore and the message structure and delta formats can handle it in context.

Maybe the combination of category.type is equivalent to type while all types are unique

Just thinking - json is not xml - we can have multiple top level keys -

{
   "vessels": {},
   "shore": {}
}

is perfectly valid? So if we convert to xml or similar the implicit root tag is marine ?