Provide namespace support for id numbers

[mjkoster]

Per the August 30 teleconference, we should support namespaces for id numbers.
The default namespace will apply to every place the "id" quality is used, and we will add a new quality "alternateId" which contains an array of zero or more id numbers which are prefixed by the identifiers for the defined namespaces. For example:

namespace {
  odm http://example.com/odm#
  foo http://example.com/foo#
  bar http://example.com/bar#
}
defaultnamespace odm

odmObject {
  temperature {
    id 467
    alternateId [ { foo 303 } { bar 3303 } ]
    odmProperty {
      temperature {
        id 468
        alternateId [ { foo 1066 } { bar 5190 } ]
        type number
      }
    }
  }
}

[gerickson]

@mjkoster, thanks for driving this forward based on the conversation on call this morning. What are your thoughts for indicating IDs (if available) for "odm", "foo", and "bar" themselves in the "namespace { ... }" declaration?

[mjkoster]

namespace { 
  odm {
    id 23
    baseuri http://example.com/odm#
  }
  foo {
    id 37
    baseuri http://example.com/foo#
  }
  bar {
    id 179
    baseuri http://example.com/bar#
  }
}

The impact of this is registered namespace IDs (and namespace names?)

A protocol binding could use 23:467/468 to refer to the temperature Property defined above

Would 37:303/1066 and 179:3303/5190 be aliases for the same Property in other namespaces?

If we write up SDF in an internet draft, we can use IANA for the namespace registry (?)

[WAvdBeek]

this means that all origins are kept in the oneDM accepted models.
not sure if that is the solution.

for now: OCF will use the OCF namespace and MD5 generated numbers for everything.

[GordonMcKinney]

@mjkoster this issue looks good... I like the idea of defining the namespace in a XML schema pattern.

Our company is discussing internally using a URN schema, very similar to what you have. Given legal I cannot reproduce our proposal but I can posit a URN for ODM... Please take this as a guide rather than a proposal:

odm:<org>:<id>

which would lead to the following examples:

odm:foo:1066
odm:bar:5190

NOTE: The odm: is repeated for every URN but this is required to prevent future URNs from other external systems causing a collision.

NOTE: This URN scheme removes the need for a namespace block with the assumption that the OneDM organization would maintain a master list of organizations, <org>, to prevent collision at that level of the URN. The master org list could be managed in a simple GitHub file with the usual PR process to add new orgs

Thoughts?

[gerickson]

@GordonMcKinney, thanks for chiming in on this. If I understand your proposal, generally, the format is:

odm:<map>

where <map> expands to { <key> : <id> }? If I were then to apply this pattern in the Weave / WDL world, <id> actually further expands to another <map> of { <key> : <id> }. Then, based on this header file, I would have:

• odm:weave:common:0x0000
• odm:weave:nestlabs:0x235A
• odm:weave:google:0xE100
• odm:weave:yale:0xE727

This would imply that in schema I should be able to either reference odm:weave:common or odm:weave:0x0000 equivalently in SDF, right?

This would also further imply that non-decorated tags / identifiers elsewhere are assumed to be context-specific tags / identifiers, for example:

{ id: 5 }

unless fully-qualified, for example:

{ id: odm:weave:common:5 }

[GordonMcKinney]

@gerickson yes... more formally here: https://en.wikipedia.org/wiki/Uniform_Resource_Name

By defining odm: at the beginning you're free to define your own rules... similar to AWS's arn: scheme.

[WAvdBeek]

not sure if I agree with this line of thinking anymore.
now it looks that there is 1 model, but originating from different SDOs.
I thought that oneDM only should have 1 definition.
hence if there is equivalancy to another eco system, I think that should be solved by that eco system and not by oneDM.

my opinion is that the name space is ONLY for avoiding number clashes on the various submissions of models.
hence we only should have 1 name space per model.

[mjkoster]

If I understand correctly, we need ID numbers for the namespaces as well.

I think we will need to register the prefix number(s) for each organization

If we want to get a urn for odm we can do that also, and we can define our own rules for the construction of identifiers

So officially it can be odm:// where orgid is a registered numeric prefix.

"odm:50/1099/3224"

So how is this interoperable?

[asoloway64]

F2F4: Need a canonical ODM number for things, objects, properties, actions and events. Need a mechanism to map between the ODM canonical number and each ecosystem number.

[asoloway64]

F2F4 Proposed Solution: ID qualities shall not be captured in the ODM thing/object/property/action/event definition. Provide a generic mechanism to map between a URI and a number. This mapping can be used to create a mapping between the ODM URI and the ODM number or any other ecosystem number. The mapping file shall be machine readable.

[gerickson]

Does the F2F4 group have a concrete example of this? In a variety of ecosystems, numbers are a shorthand part of a path whereas a URI is usually a complete path.

[asoloway64]

That is correct, so the file that captures a URI to number mapping is just that. That URI can be at a thing level, object level, or property/action/event level. Each ecosystem can provides its own number for a URI. If you start with the URI, you can get the number of any ecosystem you would like to use as a shortcut, even ODM. If you start with the number and you know which ecosystem it came from, then you can map to the URI or the number of any other ecosystem.

[mjkoster]

{
  "idmapping": {
    "wdl:/#odmObject/thermostat": 227,
    "wdl:/#odmProperty/currentTemperature": 291,
    "wdl:/#odmAction/setCoolingSetpoint": 301
  }
}