Open mjkoster opened 4 years ago
@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?
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 (?)
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.
@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?
@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 }
@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.
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.
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:
"odm:50/1099/3224"
So how is this interoperable?
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.
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.
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.
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.
{
"idmapping": {
"wdl:/#odmObject/thermostat": 227,
"wdl:/#odmProperty/currentTemperature": 291,
"wdl:/#odmAction/setCoolingSetpoint": 301
}
}
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: