-
Notifications
You must be signed in to change notification settings - Fork 8
NOTE: Link information for data models
Scratchpad for information and pointers for "link" information for data models, in particular for SDF
Links are a general concept that can be useful in SDF specifications in many ways.
-
Links can be used at the SDF specification level to make the model more concise or to provide additional information.
-
A unit specification is a rather specific kind of specification-level link.
- We actually have also talked about a unit data type, this would be related, but clearly different.
-
sdfRef uses a link for referencing an existing SDF definition in another place, enabling re-use (with potential extension) of that definition.
-
sdfRefFrom has been proposed to record similarities between SDF definitions
-
A proposal for an sdfType "link" is at https://cabo.github.io/sdftype-link/draft-bormann-asdf-sdftype-link.html
-
-
Links can be data in the information model, used as input or output of specific interactions. We still need to find out what kind of type information we want to specify for these link data.
- "link data type" (or property), currently not explicitly specified for SDF, can contain values that can be interpreted as a link to e.g., other SDF / ecosystem model definitions, other resources (i.e., any URL), named items (e.g., URNs), etc.
- sdfRelation appears to define a link data type, but then also claims it adds "ability to describe additional information on how different definitions relate to each other." This needs to be clarified.
There are two types of link data types in LwM2M: CoRE links (RFC6690) and Object Links. CoRE link “is used to refer to Resources on a LWM2M Client and their attributes” and Object Link “is used to refer to an Instance of a given Object” (essentially a pair of Object and Object Instance IDs).
More like LwM2M CoRE links.
https://github.com/Azure/opendigitaltwins-dtdl/blob/master/DTDL/v2/DTDL.v2.md#relationship
Have a very flexible way to add specification level links.
The "link data type" links could be modeled in various different ways in SDF. More exploration is needed to determine best option.
Possibilities include:
New "sdfFormat" keyword with a value "link" (or more specific, like "core-link" and "obj-link") to indicate that a string value has certain format and semantics (similar to JSO "format" keyword but with SDF specific values). Open question: should we support formats from namespaces, like "oma:objLink", or should those all be registered instead?
{
"sdfProperty": {
"LinkToResource": {
"type": "string",
"sdfFormat": "core-link"
}
}
}Adding new sdfType "link" (and/or "core-link" and "object-link"). Same registry / namespace considerations apply as for sdfFormat.
{
"sdfProperty": {
"LinkToResource": {
"type": "string",
"sdfType": "core-link"
}
}
}These are essentially two syntactic ways to describe the same information. Whatever is chosen, sdfFormat and sdfType could include a registry for more detailed link types for ecosystems. For OMA models, we need a way to tell apart CoRE Links and Object Links for OMA models. The former may be a generic type but Object Link is likely an ecosystem specific representation (which should concern us at the information model level only in terms of limitations to what kinds of links can be represented).
type could be object allowing breaking down the link structure to separate components. CoRE target attributes registry could be used for reserved words (target attributes, etc.) like href, rel, etc. Gives also semantics for names. Could also use JSO to constrain parts, like rel (using enum?).
{
"sdfProperty": {
"LinkToResource": {
"type": "object",
"sdfType": "core-link"
}
}
}This enables to use common format for various serializations. For example
{
"href" : "coaps://dev.example.com/sensor",
"if" : "temp"
}instead of ecosystem specific (in this case CoRE link format) <coaps://dev.example.com/sensor>;if=temp
Note that in an sdfAction, a link is returned as a Location.
There is currently no way to become more specific about the type of that link.
Specifying an sdfObject for that resource is one way to provide information of this kind.
This is useful or link data in general.
{
"sdfRelation": {
"LinkToResource": {
"somethingspecialhere" : true
}
}
}As sdfRelation is not fully defined at this point, this is harder to relate to the SDF type system.
- How do specific ecosystems use or define links?