Semantic Definition Format (SDF): Mapping files
Internet-Draft draft-bormann-asdf-sdf-mapping-04
Carsten Bormann, Ed.
Universität Bremen TZI
Postfach 330440
Bremen
D-28359
Germany
+49-421-218-63921
cabo@tzi.org
Jan Romann
Universität Bremen
Germany
jan.romann@uni-bremen.de
04 June 2024
Applications
ASDF
Internet-Draft
The Semantic Definition Format (SDF) is a format for domain experts to use in the creation and maintenance of data and interaction models that describe Things, i.e., physical objects that are available for interaction over a network. It was created as a common language for use in the development of the One Data Model liaison organization (OneDM) models. Tools convert this format to database formats and other serializations as needed.
An SDF specification often needs to be augmented by additional information that is specific to its use in a particular ecosystem or application. SDF mapping files provide a mechanism to represent this augmentation.
About This Document
Status information for this document may be found at https://datatracker.ietf.org/doc/draft-bormann-asdf-sdf-mapping/.
Discussion of this document takes place on the A Semantic Definition Format for Data and Interactions of Things (asdf) Working Group mailing list (mailto:asdf@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/asdf/. Subscribe at https://www.ietf.org/mailman/listinfo/asdf/.
Source for this draft and an issue tracker can be found at https://github.com/cabo/sdf-mapping.
Introduction
The Semantic Definition Format (SDF) is a format for domain experts to use in the creation and maintenance of data and interaction models that describe Things, i.e., physical objects that are available for interaction over a network. It was created as a common language for use in the development of the One Data Model liaison organization (OneDM) models. Tools convert this format to database formats and other serializations as needed.
An SDF specification often needs to be augmented by additional information that is specific to its use in a particular ecosystem or application. SDF mapping files provide a mechanism to represent this augmentation.
Terminology and Conventions
The definitions of [I-D.ietf-asdf-sdf] apply.
The term "byte" is used in its now-customary sense as a synonym for "octet".
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
Overview
An SDF mapping file provides augmentation information for one or more SDF models. Its main contents is a map from SDF name references (Section 4.3 of [I-D.ietf-asdf-sdf]) to a set of qualities.
When processing the mapping file together with one or more SDF models, these qualities are added to the SDF model at the referenced name, as in a merge-patch operation [RFC7396]. Note that this is somewhat similar to the way sdfRef (Section 4.4 of [I-D.ietf-asdf-sdf]) works, but in a mapping file the arrows point in the inverse direction (from the augmenter to the augmented).
Example Model 1 (ecosystem: IPSO/OMA)
An example for an SDF mapping file is given in Figure 1. This mapping file is meant to attach to an SDF specification published by OneDM, and to add qualities relevant to the IPSO/OMA ecosystem.
Note that this example uses namespaces to identify elements of the referenced specification(s), but has un-namespaced quality names. These two kinds of namespaces are probably unrelated, and we may need to add quality namespacing to SDF (independent of a potential feature to add namespace references to definitions that are not intended to go into the default namespace — these are SDF definition namespaces and not quality namespaces, which are one meta-level higher).
- Start of mapping file for certain OneDM playground models:
A simple example of an SDF mapping file

{
  "info": {
    "title": "IPSO ID mapping"
  },
  "namespace": {
    "onedm": "https://onedm.org/models"
  },
  "defaultNamespace": "onedm",
  "map": {
    "#/sdfObject/Digital_Input": {
      "id": 3200
    },
    "#/sdfObject/Digital_Input/sdfProperty/Digital_Input_State": {
      "id": 5500
    },
    "#/sdfObject/Digital_Input/sdfProperty/Digital_Input_Counter": {
      "id": 5501
    }
  }
}

Example Model 2 (ecosystem: W3C WoT)
This example shows a translation of a hypothetical W3C WoT Thing Model into an SDF model plus a mapping file to catch Thing Model attributes that don't currently have SDF qualities defined.
The example probably would be more useful with, say, protocol bindings. This is left for a future version of this example, and/or a future specification that specifically addresses how to map Thing Models into SDF.
(There is also the separate requirement to transform a Thing Description into the kind of information that can be represented in SDF plus instance information, such as IP addresses or specific node names.)
Finally, namespaces are all wrong in this example.
- The input: WoT Thing Model
Input: WoT Thing Model

{
    "@context": ["http://www.w3.org/ns/td"],
    "@type" : "tm:ThingModel",
    "title": "Lamp Thing Model",
    "titles": {
      "en": "Lamp Thing Model",
      "de": "Thing Model für eine Lampe"
    },
    "properties": {
        "status": {
            "description": "Current status of the lamp",
            "descriptions": {
              "en": "Current status of the lamp",
              "de": "Aktueller Status der Lampe"
            },
            "type": "string",
            "readOnly": true
        }
    }
}

- The output: SDF model
Output 1: SDF Model

{
  "info": {
    "title": "Lamp Thing Model"
  },
  "namespaces": {
    "wot": "http://www.w3.org/ns/td"
  },
  "defaultNamespace": "wot",
  "sdfObject": {
    "LampThingModel": {
      "label": "Lamp Thing Model",
      "sdfProperty": {
        "status": {
          "description": "Current status of the lamp",
          "writable": false,
          "type": "string"
        }
      }
    }
  }
}

- The other output: SDF mapping file
Output 2: SDF Mapping File

{
  "info": {
    "title": "Lamp Thing Model: WoT TM mapping"
  },
  "namespace": {
    "wot": "http://www.w3.org/ns/td"
  },
  "defaultNamespace": "wot",
  "map": {
    "#/sdfObject/LampThingModel": {
      "titles": {
        "en": "Lamp Thing Model",
        "de": "Thing Model für eine Lampe"
      }
    },
    "#/sdfObject/LampThingModel/sdfProperty/status": {
      "descriptions": {
        "en": "Current status of the lamp",
        "de": "Aktueller Status der Lampe"
      }
    }
  }
}

Formal Syntax of SDF mapping files
An SDF mapping file has three optional components that are taken unchanged from SDF: The info block, the namespace declaration, and the default namespace. The mandatory fourth component, the "map", contains the mappings from an SDF name reference (usually a namespace and a JSON pointer) to a nested map providing a set of qualities to be merged in at the site identified in the name reference.
Figure 5 describes the syntax of SDF mapping files using CDDL [RFC8610].
CDDL definition of SDF mapping file

start = sdf-mapping

sdf-mapping = {
 ; info will be required in most process policies
 ? info: sdfinfo
 ? namespace: named<text>
 ? defaultNamespace: text
 map: { * global-sdf-pointer => additionalqualities}
}

; we can't really be much more specific here:
additionalqualities = named<any>

; --------------------------------- import from SDF-base:

sdfinfo = {
 ? title: text
 ? description: text
 ? version: text
 ? copyright: text
 ? license: text
 ? modified: modified-date-time
 ? features: [
               * (any .feature "feature-name") ; EXTENSION-POINT
             ]
 optional-comment
 EXTENSION-POINT<"info-ext">
}

; Shortcut for a map that gives names to instances of X
; (has keys of type text and values of type X)
named<X> = { * text => X }

; EXTENSION-POINT is only used in framework syntax
EXTENSION-POINT<f> = ( * (quality-name .feature f) => any )
quality-name = text .regexp "([a-z][a-z0-9]*:)?[a-z$][A-Za-z$0-9]*"

; rough CURIE or JSON Pointer syntax:
global-sdf-pointer = text .regexp ".*[:#].*"

optional-comment = (
 ? $comment: text       ; source code comments only, no semantics
)

modified-date-time = text .abnf modified-dt-abnf
modified-dt-abnf = "modified-dt" .det rfc3339z

; RFC 3339 sans time-numoffset, slightly condensed
rfc3339z = '
   date-fullyear   = 4DIGIT
   date-month      = 2DIGIT  ; 01-12
   date-mday       = 2DIGIT  ; 01-28, 01-29, 01-30, 01-31 based on
                             ; month/year
   time-hour       = 2DIGIT  ; 00-23
   time-minute     = 2DIGIT  ; 00-59
   time-second     = 2DIGIT  ; 00-58, 00-59, 00-60 based on leap sec
                             ; rules
   time-secfrac    = "." 1*DIGIT
   DIGIT           =  %x30-39 ; 0-9

   partial-time    = time-hour ":" time-minute ":" time-second
                     [time-secfrac]
   full-date       = date-fullyear "-" date-month "-" date-mday

   modified-dt     = full-date ["T" partial-time "Z"]
'

IANA Considerations
Media Type
IANA is requested to add the following Media-Type to the "Media Types" registry.
A media type for SDF mapping files
Name | Template | Reference
sdf-mapping+json | application/sdf-mapping+json | RFC XXXX, Section 4.1
RFC Editor: please replace RFC XXXX with this RFC number and remove this note.
Type name:
application
Subtype name:
sdf-mapping+json
Required parameters:
none
Optional parameters:
none
Encoding considerations:
binary (JSON is UTF-8-encoded text)
Security considerations:
Section 5 of RFC XXXX
Interoperability considerations:
none
Published specification:
Section 4.1 of RFC XXXX
Applications that use this media type:
Tools for data and interaction modeling that describes Things, i.e., physical objects that are available for interaction over a network
Fragment identifier considerations:
A JSON Pointer fragment identifier may be used, as defined in Section 6 of [RFC6901].
Person & email address to contact for further information:
ASDF WG mailing list (asdf@ietf.org), or IETF Applications and Real-Time Area (art@ietf.org)
Intended usage:
COMMON
Restrictions on usage:
none
Author/Change controller:
IETF
Provisional registration:
no
Registries
(TBD: After any future additions, check if we need any.)
Security Considerations
Some wider issues are discussed in [RFC8576].
(Specifics: TBD.)
References
Normative References
[RFC6901]

JavaScript Object Notation (JSON) Pointer
P. Bryan, Ed.
K. Zyp
M. Nottingham, Ed.
April 2013
RFC 6901
DOI 10.17487/RFC6901
[RFC8610]

Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures
H. Birkholz
C. Vigano
C. Bormann
June 2019
RFC 8610
DOI 10.17487/RFC8610
[RFC7396]

JSON Merge Patch
P. Hoffman
J. Snell
October 2014
RFC 7396
DOI 10.17487/RFC7396
[I-D.ietf-asdf-sdf]

Semantic Definition Format (SDF) for Data and Interactions of Things
Michael Koster
KTC
Carsten Bormann
Universität Bremen TZI
Ari Keränen
Ericsson
28 February 2024
Internet-Draft draft-ietf-asdf-sdf-18
[RFC2119]

Key words for use in RFCs to Indicate Requirement Levels
S. Bradner
March 1997
BCP 14
RFC 2119
DOI 10.17487/RFC2119
[RFC8174]

Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words
B. Leiba
May 2017
BCP 14
RFC 8174
DOI 10.17487/RFC8174
Informative References
[RFC8576]

Internet of Things (IoT) Security: State of the Art and Challenges
O. Garcia-Morchon
S. Kumar
M. Sethi
April 2019
RFC 8576
DOI 10.17487/RFC8576
Acknowledgements
This draft is based on discussions in the Thing-to-Thing Research Group (T2TRG) and the SDF working group. Input for Section 2.1 was provided by Ari Keränen.