Internet-Draft | SDF Mapping | November 2021 |
Bormann & Romann | Expires 11 May 2022 | [Page] |
The Semantic Definition Format (SDF) is a format for domain experts to use in the creation and maintenance of data and interaction models in the Internet of Things. It was created as a common language for use in the development of the One Data Model liaison organization (OneDM) definitions. 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.¶
This note is to be removed before publishing as an RFC.¶
Discussion of this document takes place on the asdf Working Group mailing list (asdf@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/asdf/.¶
Source for this draft and an issue tracker can be found at https://github.com/cabo/sdf-mapping.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 11 May 2022.¶
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.¶
The Semantic Definition Format (SDF) is a format for domain experts to use in the creation and maintenance of data and interaction models in the Internet of Things. It was created as a common language for use in the development of the One Data Model liaison organization (OneDM) definitions. 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.¶
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.¶
An SDF mapping file provides augmentation information for one or more SDF definitions. 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 definitions, these qualities are added to the SDF definition 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).¶
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).¶
{ "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 } } }
This example shows a the 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.¶
{ "@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 } } }
{ "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" } } } } }
{ "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" } } } }
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 a 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].¶
start = sdf-mapping sdf-mapping = { ? info: sdfinfo ; This will be required in most process policies, but not a syntax error ? namespace: named<text> ? defaultNamespace: text ? map: { * sdf-pointer => additionalqualities} } ; we can't really be much more specific here: additionalqualities = named<any> ; --------------------------------- import from SDF: sdfinfo = { ? title: text ? version: text ? copyright: text ? license: text EXTENSION-POINT<"info-ext"> } ; Shortcut for a map that gives names to instances of X (has text keys and values of type X) named<X> = { * text => X } EXTENSION-POINT<f> = ( * (text .feature f) => any ) ; only used in framework syntax sdf-pointer = text ; .regexp curie-regexp -- TO DO!
IANA is requested to add the following Media-Type to the "Media Types" registry.¶
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.¶
application¶
sdf-mapping+json¶
none¶
none¶
binary (JSON is UTF-8-encoded text)¶
none¶
Section 4.1 of RFC XXXX¶
Tools for data and interaction modeling in the Internet of Things¶
A JSON Pointer fragment identifier may be used, as defined in Section 6 of [RFC6901].¶
ASDF WG mailing list (asdf@ietf.org), or IETF Applications and Real-Time Area (art@ietf.org)¶
COMMON¶
none¶
IETF¶
no¶
(TBD: After future additions, check if we need any.)¶
Some wider issues are discussed in [RFC8576].¶
(Specifics: TBD.)¶
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.¶