[要約] RFC 8477は、2016年のIoTセマンティック相互運用性ワークショップの報告書です。このRFCの目的は、IoTデバイス間の相互運用性を向上させるためのセマンティックモデルとプロトコルの提案を提供することです。
Internet Architecture Board (IAB) J. Jimenez
Request for Comments: 8477 H. Tschofenig
Category: Informational D. Thaler
ISSN: 2070-1721 October 2018
Report from the Internet of Things (IoT) Semantic Interoperability (IOTSI) Workshop 2016
モノのインターネット（IoT）セマンティックインターオペラビリティ（IOTSI）ワークショップ2016からのレポート
Abstract
概要
This document provides a summary of the "Workshop on Internet of Things (IoT) Semantic Interoperability (IOTSI)", which took place in Santa Clara, California March 17-18, 2016. The main goal of the workshop was to foster a discussion on the different approaches used by companies and Standards Developing Organizations (SDOs) to accomplish interoperability at the application layer. This report summarizes the discussions and lists recommendations to the standards community. The views and positions in this report are those of the workshop participants and do not necessarily reflect those of the authors or the Internet Architecture Board (IAB), which organized the workshop. Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the workshop participants and do not necessarily reflect IAB views and positions.
このドキュメントでは、2016年3月17〜18日、カリフォルニア州サンタクララで開催された「モノのインターネット（IoT）のセマンティックインターオペラビリティ（IOTSI）に関するワークショップ」の概要を説明します。ワークショップの主な目的は、アプリケーション層で相互運用性を実現するために企業や標準開発組織（SDO）が使用するさまざまなアプローチ。このレポートは、議論を要約し、標準化コミュニティへの推奨事項をリストします。このレポートの見解と見解はワークショップ参加者の見解と見解であり、必ずしも作者やワークショップを開催したインターネットアーキテクチャボード（IAB）の見解と反映しているわけではありません。なお、本資料はワークショップの議事録です。このレポートに記載されている見解と見解はワークショップ参加者のものであり、必ずしもIABの見解と見解を反映しているわけではありません。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Architecture Board (IAB) and represents information that the IAB has deemed valuable to provide for permanent record. It represents the consensus of the Internet Architecture Board (IAB). Documents approved for publication by the IAB are not candidates for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントはインターネットアーキテクチャボード（IAB）の製品であり、IABが永続的な記録を提供するために価値があると見なした情報を表しています。これは、インターネットアーキテクチャボード（IAB）のコンセンサスを表しています。 IABによって公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8477.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8477で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2018 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. What Problems to Solve . . . . . . . . . . . . . . . . . . . 5
4. Translation . . . . . . . . . . . . . . . . . . . . . . . . . 7
5. Dealing with Change . . . . . . . . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. Collaboration . . . . . . . . . . . . . . . . . . . . . . . . 11
9. Informative References . . . . . . . . . . . . . . . . . . . 12
Appendix A. Program Committee . . . . . . . . . . . . . . . . . 14
Appendix B. Accepted Position Papers . . . . . . . . . . . . . . 14
Appendix C. List of Participants . . . . . . . . . . . . . . . . 17
IAB Members at the Time of Approval . . . . . . . . . . . . . . . 18
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
The Internet Architecture Board (IAB) holds occasional workshops designed to consider long-term issues and strategies for the Internet, and to suggest future directions for the Internet architecture. The investigated topics often require coordinated efforts from many organizations and industry bodies to improve an identified problem. One of the targets of the workshops is to establish communication between relevant organizations, especially when the topics are out of the scope of the Internet Engineering Task Force (IETF). This long-term planning function of the IAB is complementary to the ongoing engineering efforts performed by working groups of the IETF.
インターネットアーキテクチャボード（IAB）は、インターネットの長期的な問題と戦略を検討し、インターネットアーキテクチャの将来の方向性を提案するように設計されたワークショップを時折開催します。調査されたトピックは、多くの場合、特定された問題を改善するために多くの組織や業界団体からの調整された取り組みを必要とします。ワークショップのターゲットの1つは、特にトピックがインターネット技術特別調査委員会（IETF）の範囲外である場合に、関連組織間のコミュニケーションを確立することです。 IABのこの長期計画機能は、IETFのワーキンググループによって実行されている継続的なエンジニアリングの取り組みを補完するものです。
With the expansion of the Internet of Things (IoT), interoperability becomes more and more important. Standards Developing Organizations (SDOs) have done a tremendous amount of work to standardize new protocols and profile existing protocols.
モノのインターネット（IoT）の拡大に伴い、相互運用性がますます重要になっています。標準化開発組織（SDO）は、新しいプロトコルを標準化し、既存のプロトコルをプロファイリングするために多大な労力を費やしました。
At the application layer and at the level of solution frameworks, interoperability is not yet mature. Particularly, the work on data formats (in the form of data models and information models) has not seen the same level of consistency throughout SDOs.
アプリケーション層とソリューションフレームワークのレベルでは、相互運用性はまだ成熟していません。特に、（データモデルと情報モデルの形式の）データ形式に関する作業では、SDO全体で同じレベルの一貫性は確認されていません。
One common problem is the lack of an encoding-independent standardization of the information, the so-called information model. Another problem is the strong relationship between data formats and the underlying communication architecture, such as a design in Remote Procedure Call (RPC) style or a RESTful design (where REST refers to Representational State Transfer). Furthermore, groups develop solutions that are very similar on the surface but differ slightly in their standardized outcome, leading to interoperability problems. Finally, some groups favor different encodings for use with various application-layer protocols.
よくある問題の1つは、エンコードに依存しない情報の標準化、いわゆる情報モデルがないことです。もう1つの問題は、リモートプロシージャコール（RPC）スタイルの設計やRESTful設計（RESTが表現状態転送を指す）など、データ形式と基礎となる通信アーキテクチャとの強い関係です。さらに、グループは表面的には非常に似ているが、標準化された結果がわずかに異なるソリューションを開発し、相互運用性の問題を引き起こしています。最後に、いくつかのグループは、さまざまなアプリケーション層プロトコルで使用するために異なるエンコーディングを支持しています。
Thus, the IAB decided to organize a workshop to reach out to relevant stakeholders to explore the state of the art and identify commonality and gaps [IOTSIAG] [IOTSIWS]. In particular, the IAB was interested to learn about the following aspects:
したがって、IABは、関連する利害関係者に連絡して最新技術を調査し、共通点とギャップを特定するワークショップを組織することを決定しました[IOTSIAG] [IOTSIWS]特に、IABは以下の側面について学ぶことに興味がありました。
o What is the state of the art in data and information models? What should an information model look like?
o データおよび情報モデルの最先端技術とは何ですか？情報モデルはどのように見えるべきですか？
o What is the role of formal languages, such as schema languages, in describing information and data models?
o 情報とデータモデルの記述におけるスキーマ言語などの正式言語の役割は何ですか？
o What is the role of metadata, which is attached to data to make it self-describing?
o 自己記述的にするためにデータに添付されるメタデータの役割は何ですか？
o How can we achieve interoperability when different organizations, companies, and individuals develop extensions?
o さまざまな組織、企業、個人が拡張機能を開発する場合、どのようにして相互運用性を実現できますか？
o What is the experience with interworking various data models developed from different groups, or with data models that evolved over time?
o 異なるグループから開発されたさまざまなデータモデルの相互作用、または時間の経過とともに進化したデータモデルの経験とは何ですか？
o What functionality should online repositories for sharing schemas have?
o スキーマを共有するためのオンラインリポジトリにはどのような機能が必要ですか？
o How can existing data models be mapped against each other to offer interworking?
o 既存のデータモデルを相互にマッピングして、インターワーキングを提供するにはどうすればよいですか？
o Is there room for harmonization, or are the use cases of different groups and organizations so unique that there is no possibility for cooperation?
o 調和の余地はありますか、またはさまざまなグループや組織のユースケースが非常にユニークなため、協力の可能性はありませんか？
o How can organizations better work together to increase awareness and information sharing?
o 意識を高め、情報を共有するために、組織はどのようにしてより効果的に連携できるでしょうか
The first roadblock to interoperability at the level of data models is the lack of a common vocabulary to start the discussion. [RFC3444] provides a starting point by separating conceptual models for designers, or "information models", from concrete detailed definitions for implementers, or "data models". There are concepts that are undefined in that RFC and elsewhere, such as the interaction with the resources of an endpoint, or "interaction model". Therefore, the three "main" common models that were identified were:
データモデルのレベルでの相互運用性への最初の障害は、議論を始めるための一般的な語彙の欠如です。 [RFC3444]は、設計者の概念モデル、つまり「情報モデル」を、実装者の具体的な詳細定義、つまり「データモデル」から分離することにより、開始点を提供します。エンドポイントのリソースとの相互作用、または「相互作用モデル」など、そのRFCや他の場所で定義されていない概念があります。したがって、識別された3つの「主な」共通モデルは次のとおりです。
Information Model An information model defines an environment at the highest level of abstraction and expresses the desired functionality. Information models can be defined informally (e.g., in prose) or more formally (e.g., Unified Modeling Language (UML), Entity-Relationship Diagrams, etc.). Implementation details are hidden.
情報モデル情報モデルは、最高レベルの抽象化で環境を定義し、必要な機能を表現します。情報モデルは、非公式に（例：散文で）、またはより正式に（例：統一モデリング言語（UML）、エンティティ関係図など）に定義できます。実装の詳細は非表示です。
Data Model A data model defines concrete data representations at a lower level of abstraction, including implementation- and protocol-specific details. Some examples are SNMP Management Information Base (MIB) modules, World Wide Web Consortium (W3C) Thing Description (TD) Things, YANG modules, Lightweight Machine-to-Machine (LwM2M) Schemas, Open Connectivity Foundation (OCF) Schemas, and so on.
データモデルデータモデルは、実装およびプロトコル固有の詳細を含む、抽象化のより低いレベルでの具体的なデータ表現を定義します。いくつかの例は、SNMP管理情報ベース（MIB）モジュール、World Wide Webコンソーシアム（W3C）Thing Description（TD）モノ、YANGモジュール、軽量Machine-to-Machine（LwM2M）スキーマ、Open Connectivity Foundation（OCF）スキーマなどです。オン。
Interaction Model An interaction model defines how data is accessed and retrieved from the endpoints, being, therefore, tied to the specific communication pattern that the system has (e.g., REST methods, Publish/Subscribe operations, or RPC calls).
相互作用モデル相互作用モデルは、データがエンドポイントからアクセスおよび取得される方法を定義します。したがって、システムが持つ特定の通信パターン（RESTメソッド、パブリッシュ/サブスクライブ操作、またはRPCコールなど）に関連付けられます。
Another identified terminology issue is the semantic meaning overload that some terms have. The meaning can vary depending on the context in which the term is used. Some examples of such terms are as follows: semantics, models, encoding, serialization format, media types, and encoding types. Due to time constraints, no concrete terminology was agreed upon, but work will continue within each organization to create various terminology documents. The participants agreed to set up a GitHub repository [IOTSIGIT] for sharing information.
別の識別された用語の問題は、一部の用語が持つ意味のオーバーロードです。意味は、その用語が使用されているコンテキストによって異なります。そのような用語のいくつかの例は次のとおりです：セマンティクス、モデル、エンコーディング、シリアル化形式、メディアタイプ、エンコーディングタイプ。時間の制約により、具体的な用語については合意されていませんが、各組織内でさまざまな用語のドキュメントを作成する作業が継続されます。参加者は、情報を共有するためのGitHubリポジトリ[IOTSIGIT]を設定することに同意しました。
The participants agreed that there is not simply a single problem to be solved but rather a range of problems. During the workshop, the following problems were discussed:
参加者は、解決すべき単一の問題ではなく、さまざまな問題があることに同意しました。ワークショップでは、以下の問題が議論されました：
o Formal Languages for Documentation Purposes
o 文書化のための正式な言語
To simplify review and publication, SDOs need formal descriptions of their data and interaction models. Several of them use a tabular representation found in the specification itself but use a formal language as an alternative way of describing objects and resources for formal purposes. Some examples of formal language use are as follows.
レビューと公開を簡素化するために、SDOはデータと相互作用モデルの正式な説明を必要とします。それらのいくつかは、仕様自体にある表形式の表現を使用しますが、正式な目的でオブジェクトとリソースを記述する代替方法として、正式な言語を使用します。正式な言語の使用例は次のとおりです。
The Open Mobile Alliance (OMA), now OMA SpecWorks, used an XML Schema [LWM2M-Schema] to describe their object and resource definitions. The XML files of standardized objects are available for download at [OMNA].
Open Mobile Alliance（OMA）（現在はOMA SpecWorks）は、XMLスキーマ[LWM2M-Schema]を使用して、オブジェクトとリソースの定義を記述していました。標準化されたオブジェクトのXMLファイルは、[OMNA]からダウンロードできます。
The Bluetooth Special Interest Group (SIG) defined Generic Attribute Profile (GATT) services and characteristics for use with Bluetooth Smart/Low Energy. The services and characteristics are shown in a tabular form on the Bluetooth SIG website [SIG] and are defined as XML instance documents.
Bluetooth Special Interest Group（SIG）は、Bluetooth Smart / Low Energyで使用するGeneric Attribute Profile（GATT）サービスと特性を定義しました。サービスと特性は、Bluetooth SIG Webサイト[SIG]に表形式で表示され、XMLインスタンスドキュメントとして定義されます。
The Open Connectivity Foundation (OCF) uses JSON Schemas to formally define data models and RESTful API Modeling Language (RAML) to define interaction models. The standard files are available online at <oneIoTa.org>.
Open Connectivity Foundation（OCF）はJSONスキーマを使用してデータモデルを正式に定義し、RESTful APIモデリング言語（RAML）を使用して相互作用モデルを定義します。標準ファイルは、<oneIoTa.org>からオンラインで入手できます。
The AllSeen Alliance uses AllJoyn Introspection XML to define data and interaction models in the same formal language, tailored for RPC-style interaction. The standard files are available online on the AllSeen Alliance website, but both standard and vendor-defined model files can be obtained by directly querying a device for them at runtime.
AllSeen AllianceはAllJoyn Introspection XMLを使用して、RPCスタイルの対話用に調整された同じ形式言語でデータと対話モデルを定義します。標準ファイルはAllSeen Alliance Webサイトからオンラインで入手できますが、実行時にデバイスに直接クエリを実行することにより、標準モデルファイルとベンダー定義モデルファイルの両方を取得できます。
The World Wide Web Consortium (W3C) uses the Resource Description Framework (RDF) to define data and interaction models using a format tailored for the web.
World Wide Webコンソーシアム（W3C）は、Resource Description Framework（RDF）を使用して、Web用に調整されたフォーマットを使用してデータおよび対話モデルを定義します。
The Internet Engineering Task Force (IETF) uses YANG to define data and interaction models. Other SDOs may use various other formats.
Internet Engineering Task Force（IETF）は、YANGを使用してデータと相互作用モデルを定義しています。他のSDOは他のさまざまな形式を使用する場合があります。
o Formal Languages for Code Generation
o コード生成のための形式言語
Code-generation tools that use formal data and information modeling languages are needed by developers. For example, the AllSeen Visual Studio Plugin [AllSeen-Plugin] offers a wizard to generate code based on the formal description of the data model. Another example of a data modeling language that can be used for code generation is YANG. A popular tool to help with code generation of YANG modules is pyang [PYANG]. An example of a tool that can generate code for multiple ecosystems is OpenDOF [OpenDOF]. Use cases discussed for code generation included easing development of server-side device functionality, clients, and compliance tests.
形式的なデータと情報モデリング言語を使用するコード生成ツールが開発者に必要です。たとえば、AllSeen Visual Studioプラグイン[AllSeen-Plugin]は、データモデルの正式な説明に基づいてコードを生成するウィザードを提供します。コード生成に使用できるデータモデリング言語のもう1つの例は、YANGです。 YANGモジュールのコード生成を支援する一般的なツールは、pyang [PYANG]です。複数のエコシステムのコードを生成できるツールの例は、OpenDOF [OpenDOF]です。コード生成について説明した使用例には、サーバー側のデバイス機能、クライアント、およびコンプライアンステストの開発の容易化が含まれていました。
o Debugging Support
o デバッグのサポート
Debugging tools are needed that implement generic object browsers, which use standard data models and/or retrieve formal language descriptions from the devices themselves. As one example, the nRF Bluetooth Smart sniffer from Nordic Semiconductor [nRF-Sniffer] can be used to display services and characteristics defined by the Bluetooth SIG. As another example, AllJoyn Explorer [AllJoynExplorer] can be used to browse and interact with any resource exposed by an AllJoyn device, including both standard and vendor-defined data models, by retrieving the formal descriptions from the device at runtime.
標準データモデルを使用したり、デバイス自体から正式な言語記述を取得したりする汎用オブジェクトブラウザーを実装するデバッグツールが必要です。一例として、Nordic SemiconductorのnRF Bluetooth Smartスニファ[nRF-Sniffer]を使用して、Bluetooth SIGによって定義されたサービスと特性を表示できます。別の例として、AllJoyn Explorer [AllJoynExplorer]を使用して、実行時にデバイスから正式な説明を取得することにより、AllJoynデバイスによって公開されたリソース（標準データモデルとベンダー定義データモデルの両方を含む）を参照および操作できます。
o Translation
o 翻訳
The working assumption is that devices need to have a common data model with a priori knowledge of data types and actions. However, that would imply that each consortium/organization will try to define their own data model. That would cause a major interoperability problem, possibly a completely intractable one given the number of variations, extensions, compositions, or versioning changes that will happen for each data model.
動作の前提は、デバイスがデータタイプとアクションのアプリオリな知識を持つ共通のデータモデルを持つ必要があるということです。ただし、これは、各コンソーシアム/組織が独自のデータモデルを定義しようとすることを意味します。これにより、主要な相互運用性の問題が発生します。各データモデルで発生するバリエーション、拡張、構成、またはバージョン変更の数を考えると、おそらく完全に扱いにくい問題です。
Another potential approach is to have a minimal amount of information on the device to allow for a runtime binding to a specific model, the objective being to require as little prior knowledge as possible.
別の潜在的なアプローチは、特定のモデルへのランタイムバインディングを可能にするために、デバイスに最小限の情報を持たせることです。その目的は、できる限り少ない事前知識を必要とすることです。
Moreover, gateways, bridges and other similar devices need to dynamically translate (or map) one data model to another one. Complexity will increase as there are also multiple protocols and schemas that make interoperability harder to achieve.
さらに、ゲートウェイ、ブリッジ、その他の同様のデバイスは、あるデータモデルを別のデータモデルに動的に変換（またはマップ）する必要があります。相互運用性の実現を困難にする複数のプロトコルとスキーマも存在するため、複雑さが増します。
o Runtime Discovery
o ランタイムディスカバリ
Runtime discovery allows IoT devices to exchange metadata about the data, potentially along with the data exchanged itself. In some cases, the metadata not only describes data but also the interaction model as well. An example of such an approach has been shown with Hypermedia as the Engine of Application State (HATEOAS) [HATEOAS]. Another example is that all AllJoyn devices support such runtime discovery using a protocol mechanism called "introspection", where the metadata is queried from the device itself [AllSeen].
ランタイムディスカバリにより、IoTデバイスはデータに関するメタデータを交換することができます。潜在的には、データ自体も交換されます。場合によっては、メタデータはデータだけでなく、相互作用モデルも記述します。そのようなアプローチの例は、アプリケーション状態のエンジン（HATEOAS）としてのハイパーメディア[HATEOAS]で示されています。別の例は、すべてのAllJoynデバイスが、「イントロスペクション」と呼ばれるプロトコルメカニズムを使用してそのようなランタイムディスカバリをサポートすることです。メタデータはデバイス自体からクエリされます[AllSeen]。
There are various models, whether deployed or possible, for such discovery. The metadata might be extracted from a specification, looked up on a cloud repository (e.g., oneIoTa for OCF models), looked up via a vendor's site, or obtained from the device itself (such as in the AllJoyn case). The relevant metadata might be obtained from the same place or different pieces might be obtained from different places, such as separately obtaining (a) syntax information, (b) end-user descriptions in a desired language, and (c) developer-specific comments for implementers.
このような発見には、展開されているか可能かを問わず、さまざまなモデルがあります。メタデータは、仕様から抽出したり、クラウドリポジトリ（OCFモデルのoneIoTaなど）で検索したり、ベンダーのサイトから検索したり、デバイス自体（AllJoynの場合など）から取得したりできます。関連するメタデータは、同じ場所から取得することも、異なる場所から取得することもできます。たとえば、（a）構文情報、（b）目的の言語でのエンドユーザーの説明、（c）開発者固有のコメントなど実装者向け。
In an ideal world where organizations and companies cooperate and agree on a single data model standard, there is no need for gateways that translate from one data model to another one. However, this is far from reality today, and there are many proprietary data models in addition to the already standardized ones. As a consequence, gateways are needed to translate between data models. This leads to (n^2)-n combinations, in the worst case.
組織と企業が単一のデータモデル標準に協力して合意する理想的な世界では、あるデータモデルから別のデータモデルに変換するゲートウェイは必要ありません。しかし、これは今日の現実にはほど遠く、すでに標準化されているものに加えて、多くの独自のデータモデルがあります。結果として、データモデル間で変換を行うにはゲートウェイが必要です。これにより、最悪の場合、（n ^ 2）-nの組み合わせになります。
There are analogies with gateways back in the 1980s that were used to translate between network layer protocols. Eventually, IP took over, providing the necessary end-to-end interoperability at the network layer. Unfortunately, the introduction of gateways leads to the loss of expressiveness due to the translation between data models. The functionality of IP was so valuable in the market that advanced features of other networking protocols became less attractive and were not used anymore.
ネットワーク層プロトコル間の変換に使用された1980年代のゲートウェイとの類似点があります。最終的に、IPが引き継ぎ、ネットワーク層で必要なエンドツーエンドの相互運用性を提供しました。残念ながら、ゲートウェイを導入すると、データモデル間の変換により表現力が失われます。 IPの機能は市場で非常に価値があったため、他のネットワーキングプロトコルの高度な機能は魅力がなくなり、使用されなくなりました。
Participants discussed an alternative that they called a "red star", shown in Figure 1, where data models are translated to a common data model shown in the middle. This reduces the number of translations that are needed down to 2n (in the best case). The problem, of course, is that everyone wants their own data model to be the red star in the center.
参加者は、図1に示す「赤い星」と呼ばれる別の方法について説明しました。図1では、データモデルが中央にある共通のデータモデルに変換されています。これにより、必要な変換の数が2nに減少します（最良の場合）。もちろん問題は、誰もが自分のデータモデルを中央の赤い星にしたいということです。
+-----+ +-----+
| | | |
| | -- -- | |
| | -- -- | |
+-----+ -- -- +-----+
-- ---
-- --
-- --
-- --
--- -- A -- ---
/ \ ___/ \___ / \
| | ---------------', .'--------------- | |
\ / /. ^ .\ \ /
--- /' '\ ---
-- --
-- --
-- --
-- --
-- --
/\ -- -- /\
/ \ -- -- / \
/ \ / \
/ \ / \
/--------\ /--------\
Figure 1: The "Red Star" in Data/Information Models
図1：データ/情報モデルの「赤い星」
While the workshop itself was not a suitable forum to discuss the design of such translation in detail, several questions were raised:
ワークショップ自体は、そのような翻訳の設計を詳細に議論するための適切なフォーラムではありませんでしたが、いくつかの疑問が提起されました。
o Do we need a "red star" that does everything, or could we design something that offers a more restricted functionality?
o すべてを行う「赤い星」が必要ですか、それともより制限された機能を提供するものを設計できますか？
o How do we handle loss of data and functionality? o Should data be translated between data models, or should data models themselves be translated?
oデータと機能の損失にどのように対処しますか？ oデータモデル間でデータを変換する必要がありますか、それともデータモデル自体を変換する必要がありますか？
o How can interaction models be translated? They need to be dealt with in addition to the data models.
o 相互作用モデルはどのように翻訳できますか？これらは、データモデルに加えて処理する必要があります。
o Many (if not all) data and interaction models have some bizarre functionality that cannot be translated easily. How can those be handled?
o 多くの（すべてではないにしても）データおよび相互作用モデルには、簡単に変換できない奇妙な機能があります。それらはどのように処理できますか？
o What limitations are we going to accept in these translations?
o これらの翻訳にはどのような制限がありますか？
The participants also addressed the question of when translation should be done. Two use cases were discussed:
参加者はまた、いつ翻訳を行うべきかという問題にも取り組みました。 2つの使用例について説明しました。
(a) Design time: A translation between data model descriptions, such as translating a YANG module to a RAML/JSON model, can be performed once, during design time. A single information model might be mapped to a number of different data models.
（a）設計時：YANGモジュールからRAML / JSONモデルへの変換など、データモデル記述間の変換は、設計時に1回実行できます。単一の情報モデルが複数の異なるデータモデルにマッピングされる場合があります。
(b) Run time: Runtime translation of values in two standard data models can only be algorithmically done when the data model on one side is algorithmically derived from the data model on the other side. This was called a "derived model". It was discussed that the availability of runtime discovery can aid in semantic translation, such as when a vendor-specific data model on one side of a protocol bridge is resolved and the translator can algorithmically derive the semantically equivalent vendor-specific data model on the other side. This situation is discussed in [BridgeTaxonomy].
（b）実行時：2つの標準データモデルの値のランタイム変換は、一方のデータモデルがもう一方のデータモデルからアルゴリズム的に導出されている場合にのみ、アルゴリズム的に実行できます。これは「派生モデル」と呼ばれていました。ランタイムディスカバリの可用性は、プロトコルブリッジの一方のベンダー固有のデータモデルが解決され、トランスレータがもう一方の意味的に同等のベンダー固有のデータモデルをアルゴリズムで導出できる場合など、意味変換に役立つ可能性があることが説明されました側。この状況については、[BridgeTaxonomy]で説明しています。
The participants agreed that algorithm translation will generally require custom code whenever one is translating to anything other than a derived model.
参加者は、派生モデル以外のものに変換する場合は常にアルゴリズムの変換にカスタムコードが必要になることに同意しました。
Participants concluded that it is typically easier to translate data between systems that follow the same communication architecture.
参加者は、同じ通信アーキテクチャに従うシステム間でデータを変換する方が通常は簡単であると結論付けました。
A large part of the workshop was dedicated to the evolution of devices and server-side applications. Interactions between devices and services and how their relationship evolves over time is complicated by their respective interaction models.
ワークショップの大部分は、デバイスとサーバー側アプリケーションの進化に捧げられました。デバイスとサービス間の相互作用、およびそれらの関係が時間とともにどのように進化するかは、それぞれの相互作用モデルによって複雑になります。
The workshop participants discussed various approaches to deal with change. In the most basic case, a developer might use a description of an API and implement the protocol steps. Sometimes, the data or information model can be used to generate code stubs. Subsequent changes to an API require changes on the clients to upgrade to the new version, which requires some development of new code to satisfy the needs of the new API.
ワークショップの参加者は、変化に対処するためのさまざまなアプローチについて議論しました。最も基本的なケースでは、開発者はAPIの説明を使用して、プロトコルステップを実装します。場合によっては、データまたは情報モデルを使用してコードスタブを生成できます。 APIに対するその後の変更では、クライアントを変更して新しいバージョンにアップグレードする必要があります。これには、新しいAPIのニーズを満たすために新しいコードを開発する必要があります。
These interactions could be made machine understandable in the first place, enabling for changes to happen at runtime. In that scenario, a machine client could discover the possible interactions with a service, adapting to changes as they occur without specific code being developed to adapt to them.
これらの相互作用は、最初からマシンが理解できるようにすることができ、実行時に変更を行うことができます。そのシナリオでは、マシンクライアントは、サービスとの可能な相互作用を発見し、それらに適応する特定のコードを開発せずに、発生した変更に適応できます。
The challenge seems to be to code the human-readable specification into a machine-readable format. Machine-readable languages require a shared vocabulary to give meaning to the tags.
人間が読める仕様を機械が読める形式にコード化するのは難しいようです。機械可読言語では、タグに意味を与えるために共有語彙が必要です。
These types of interactions are often based on the REST architectural style. Its principle is that a device or endpoint only needs a single entry point, with a host providing descriptions of the API in-band by means of web links and forms.
これらのタイプの対話は、RESTアーキテクチャスタイルに基づいていることがよくあります。その原則は、デバイスまたはエンドポイントが単一のエントリポイントのみを必要とし、ホストがWebリンクおよびフォームを使用してインバンドでAPIの説明を提供することです。
By defining IoT-specific relation types, it is possible to drive interactions through links instead of hard-coding URIs into a RESTful client, thus making the system flexible enough for later changes. The definition of the basic hypermedia formats for IoT is still a work in progress. However, some of the existing mechanisms can be reused, such as resource discovery, forms, or links.
IoT固有の関係タイプを定義することにより、URIをRESTfulクライアントにハードコーディングする代わりに、リンクを介して対話を駆動することが可能になり、システムを後で変更するために十分に柔軟にすることができます。 IoTの基本的なハイパーメディア形式の定義はまだ進行中です。ただし、リソースの検出、フォーム、リンクなど、既存のメカニズムの一部は再利用できます。
This document has no IANA actions.
このドキュメントにはIANAアクションはありません。
There were two types of security considerations discussed: use of formal data models for security configuration and security of data and data models in general.
議論された2つのタイプのセキュリティの考慮事項がありました：セキュリティ構成のための正式なデータモデルの使用とデータとデータモデルのセキュリティ一般。
It was observed that the security assumptions and configuration, or "security model", varies by ecosystem today, making the job of a translator difficult. For example, there are different types of security principals (e.g., user vs. device vs. application), the use of Access Control Lists (ACLs) versus capabilities, and what types of policies can be expressed, all vary by ecosystem. As a result, the security model architecture generally dictates where translation can be done.
セキュリティの前提と構成、つまり「セキュリティモデル」は、今日のエコシステムによって異なり、翻訳者の仕事を難しくしていることが観察されました。たとえば、セキュリティプリンシパルにはさまざまなタイプ（ユーザー対デバイス対アプリケーションなど）、アクセス制御リスト（ACL）の使用と機能、および表現できるポリシーのタイプがあり、すべてエコシステムによって異なります。その結果、セキュリティモデルアーキテクチャは一般に、変換を実行できる場所を決定します。
One approach discussed was whether two endpoints might be able to use some overlay security model across a translator between two ecosystems, which only works if the two endpoints agree on a common data model for their communication. Another approach discussed was simply having a translator act as a trusted intermediary, which enables the translator to translate between different data models.
議論された1つのアプローチは、2つのエンドポイントが2つのエコシステム間のトランスレータ全体でオーバーレイセキュリティモデルを使用できるかどうかでした。これは、2つのエンドポイントが通信の共通データモデルに同意した場合にのみ機能します。議論された別のアプローチは、翻訳者を信頼できる仲介者として機能させることでした。これにより、翻訳者は異なるデータモデル間で翻訳できます。
One suggestion discussed was either adding metadata into the formal data model language or having it accompany the data values over the wire, tagging the data with privacy levels. However, sometimes even the privacy level of information might itself be sensitive. Still, it was observed that being able to dynamically learn security requirements might help provide better UIs and translators.
議論された提案の1つは、正式なデータモデル言語にメタデータを追加するか、それをネットワーク上のデータ値に添付して、プライバシーレベルでデータにタグを付けることでした。ただし、情報のプライバシーレベルでさえ機密性が高い場合があります。それでも、セキュリティ要件を動的に学習できることは、より優れたUIとトランスレータの提供に役立つ可能性があることが観察されました。
The participants discussed how best to share information among their various organizations. One discussion was around having joint meetings. One current challenge reported was that organizations were not aware of when and where each other's meetings were scheduled, and sharing such information could help organizations better collocate meetings. To facilitate this exchange, the participants agreed to add links to their respective meeting schedules from a common page in the IOTSI repository [IOTSIGIT].
参加者は、さまざまな組織間で情報を共有する最良の方法について話し合いました。議論の1つは、合同会議の開催に関するものでした。報告された現在の課題の1つは、組織が互いの会議がいつどこでスケジュールされているかを認識していないことであり、そのような情報を共有することで、組織が会議をより適切に配置できるようになります。この交換を容易にするために、参加者は、IOTSIリポジトリの共通ページ[IOTSIGIT]からそれぞれの会議スケジュールへのリンクを追加することに同意しました。
Another challenge reported was that organizations did not know how to find each other's published data models, and sharing such information could better facilitate reuse of the same information model. To facilitate this exchange, the participants discussed whether a common repository might be used by multiple organizations. The OCF's oneIoTa repository was discussed as one possibility, but it was reported that its terms of use at the time of the workshop prevented this. The OCF agreed to take this back and look at updating the terms of use to allow other organizations to use it, as the restriction was not the intent. <schema.org> was discussed as another possibility. In the meantime, the participants agreed to add links to their respective repositories from a common page in the IOTSI repository [IOTSIGIT].
報告された別の課題は、組織が互いの公開されたデータモデルを見つける方法を知らなかったため、そのような情報を共有することで、同じ情報モデルの再利用が容易になることです。この交換を容易にするために、参加者は、共通のリポジトリが複数の組織で使用されるかどうかについて話し合いました。 OCFのoneIoTaリポジトリーが1つの可能性として議論されましたが、ワークショップ時の使用条件がこれを妨げていたことが報告されました。 OCFは、この制限を意図していないため、これを取り戻し、他の組織が使用できるように利用規約を更新することを検討することに同意しました。 <schema.org>は別の可能性として議論されました。その間、参加者は、IOTSIリポジトリの共通ページからそれぞれのリポジトリへのリンクを追加することに同意しました[IOTSIGIT]。
It was also agreed that the iotsi@iab.org mailing list would remain open and available for sharing information between all relevant organizations.
また、iotsi @ iab.orgメーリングリストは、オープンであり、関連するすべての組織間で情報を共有するために利用可能であることに同意しました。
[AllJoynExplorer] Microsoft, "AllJoyn".
[AllJoynExplorer] Microsoft、「AllJoyn」。
[AllSeen] Thaler, D., "Summary of AllSeen Alliance Work Relevant to Semantic Interoperability", 2016, <https://www.iab.org/ wp-content/IAB-uploads/2016/03/AllSeen-summary-IOTSI.pdf>.
[AllSeen]ターラーD.、「セマンティック相互運用性に関連するAllSeenアライアンス作業の概要」、2016年、<https://www.iab.org/ wp-content / IAB-uploads / 2016/03 / AllSeen-summary-IOTSI .pdf>。
[AllSeen-Plugin] Rockwell, B., "Using the AllJoyn Studio Extension", August 2015.
[AllSeen-Plugin]ロックウェルB。、「AllJoyn Studio拡張機能の使用」、2015年8月。
[BridgeTaxonomy] Thaler, D., "IoT Bridge Taxonomy", IAB IOTSI Workshop 2016, <https://www.iab.org/wp-content/ IAB-uploads/2016/03/DThaler-IOTSI.pdf>.
[BridgeTaxonomy] Thaler、D。、「IoT Bridge Taxonomy」、IAB IOTSI Workshop 2016、<https://www.iab.org/wp-content/ IAB-uploads / 2016/03 / DThaler-IOTSI.pdf>。
[HATEOAS] Kovatsch, M., Hassan, Y., and K. Hartke, "Semantic Interoperability Requires Self-describing Interaction Models: HATEOAS for the Internet of Things", Proceedings of the IAB IoT Semantic Interoperability Workshop 2016, <https://www.iab.org/wp-content/ IAB-uploads/2016/03/2016-IAB-HATEOAS.pdf>.
[HATEOAS] Kovatsch、M.、Hassan、Y。、およびK. Hartke、「セマンティック相互運用には自己記述型の相互作用モデルが必要：モノのインターネットのためのHATEOAS」、IAB IoTセマンティック相互運用ワークショップ2016、<https：/ /www.iab.org/wp-content/ IAB-uploads / 2016/03 / 2016-IAB-HATEOAS.pdf>。
[IOTSIAG] IAB, "IoT Semantic Interoperability Workshop Agenda", 2016, <https://www.iab.org/activities/workshops/iotsi/agenda/>.
[IOTSIAG] IAB、「IoT Semantic Interoperability Workshop Agenda」、2016年、<https://www.iab.org/activities/workshops/iotsi/agenda/>。
[IOTSIGIT] "Starting place for the IoT Semantic Interoperability Workshop (IOTSI) Information Resource", commit ff21f74, July 2018, <https://github.com/iotsi/iotsi>.
[IOTSIGIT]「IoTセマンティックインターオペラビリティワークショップ（IOTSI）情報リソースの出発点」、コミットff21f74、2018年7月、<https://github.com/iotsi/iotsi>。
[IOTSIWS] IAB, "IoT Semantic Interoperability Workshop 2016", 2016, <https://www.iab.org/activities/workshops/iotsi/>.
[IOTSIWS] IAB、「IoT Semantic Interoperability Workshop 2016」、2016、<https://www.iab.org/activities/workshops/iotsi/>。
[LWM2M-Schema] OMA, "LWM2M XML Schema - LWM2M Editor Schema", July 2018.
[LWM2M-Schema] OMA、「LWM2M XML Schema-LWM2M Editor Schema」、2018年7月。
[nRF-Sniffer] Nordic Semiconductor, "nRF Sniffer: Smart/Bluetooth low energy packet sniffer".
[nRF-Sniffer] Nordic Semiconductor、「nRF Sniffer：Smart / Bluetooth low energy packet sniffer」。
[OMNA] OMA, "OMA LightweightM2M (LwM2M) Object and Resource Registry".
[OMNA] OMA、「OMA LightweightM2M（LwM2M）オブジェクトとリソースレジストリ」。
[OpenDOF] OpenDOF, "The OpenDOF Project", <https://opendof.org>.
[OpenDOF] OpenDOF、「OpenDOFプロジェクト」、<https://opendof.org>。
[PYANG] "An extensible YANG validator and converter in python", commit 15c807f, September 2018, <https://github.com/mbj4668/pyang>.
[PYANG]「Pythonでの拡張可能なYANGバリデーターおよびコンバーター」、コミット15c807f、2018年9月、<https://github.com/mbj4668/pyang>。
[RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between Information Models and Data Models", RFC 3444, DOI 10.17487/RFC3444, January 2003, <https://www.rfc-editor.org/info/rfc3444>.
[RFC3444] Pras、A。およびJ. Schoenwaelder、「情報モデルとデータモデルの違いについて」、RFC 3444、DOI 10.17487 / RFC3444、2003年1月、<https://www.rfc-editor.org/info/ rfc3444>。
[SIG] Bluetooth SIG, "GATT Specifications", <https://www.bluetooth.com/specifications/gatt>.
[SIG] Bluetooth SIG、「GATT仕様」、<https://www.bluetooth.com/specifications/gatt>。
This workshop was organized by the following individuals: Jari Arkko, Ralph Droms, Jaime Jimenez, Michael Koster, Dave Thaler, and Hannes Tschofenig.
このワークショップは、Jari Arkko、Ralph Droms、Jaime Jimenez、Michael Koster、Dave Thaler、およびHannes Tschofenigが主催しました。
o Jari Arkko, "Gadgets and Protocols Come and Go, Data Is Forever"
o Jari Arkko、「ガジェットとプロトコルは行き来し、データは永遠です」
o Carsten Bormann, "Noise in Specifications hurts"
o Carsten Bormann、「仕様のノイズが痛い」
o Benoit Claise, "YANG as the Data Modelling Language in the IoT space"
o Benoit Claise、「IoT空間におけるデータモデリング言語としてのYANG」
o Robert Cragie, "The ZigBee Cluster Library over IP"
o Robert Cragie、「ZigBee Cluster Library over IP」
o Dee Denteneer, Michael Verschoor, and Teresa Zotti, "Fairhair: interoperable IoT services for major Building Automation and Lighting Control ecosystems"
o Dee Denteneer、Michael Verschoor、およびTeresa Zotti、「Fairhair：主要なビルディングオートメーションおよび照明制御エコシステム向けの相互運用可能なIoTサービス」
o Universal Devices, "Object Oriented Approach to IoT Interoperability"
o ユニバーサルデバイス、「IoT相互運用性へのオブジェクト指向アプローチ」
o Bryant Eastham, "Interoperability and the OpenDOF Project"
o Bryant Eastham、「相互運用性とOpenDOFプロジェクト」
o Stephen Farrell and Alissa Cooper, "It's Often True: Security's Ignored (IOTSI) - and Privacy too"
o スティーブン・ファレルとアリッサ・クーパー、「それはしばしば本当です：セキュリティは無視されます（IOTSI）-そしてプライバシーも」
o Christian Groves, Lui Yan, and Yang Weiwei, "Overview of IoT semantics landscape"
o クリスチャングローブス、ルイヤン、ヤンウェイウェイ、「IoTセマンティクスの概要」
o Ted Hardie, "Loci of Interoperability for the Internet of Things"
o テッド・ハーディ、「モノのインターネットの相互運用性の軌跡」
o Russ Housley, "Vehicle-to-Vehicle and Vehicle-to-Infrastructure Communications"
o Russ Housley、「車から車へ、車からインフラへの通信」
o Jaime Jimenez, Michael Koster, and Hannes Tschofenig, "IPSO Smart Objects"
o Jaime Jimenez、Michael Koster、およびHannes Tschofenig、「IPSO Smart Objects」
o David Jones, "IOTDB - interoperability Through Semantic Metastandards"
o David Jones、「IOTDB-セマンティックメタスタンダードによる相互運用性」
o Sebastian Kaebisch and Darko Anicic, "Thing Description as Enabler of Semantic Interoperability on the Web of Things"
o Sebastian KaebischとDarko Anicic、「モノのWebでのセマンティック相互運用性を実現するものとしてのモノの説明」
o Achilleas Kemos, "Alliance for Internet of Things Innovation Semantic Interoperability Release 2.0, AIOTI WG03 - IoT Standardisation"
o Achilleas Kemos、「モノのインターネットイノベーションセマンティックインターオペラビリティリリース2.0、AIOTI WG03-IoT標準化のための同盟」
o Ari Keraenen and Cullen Jennings, "SenML: simple building block for IoT semantic interoperability"
o Ari KeraenenおよびCullen Jennings、「SenML：IoTセマンティック相互運用性のためのシンプルなビルディングブロック」
o Dongmyoung Kim, Yunchul Choi, and Yonggeun Hong, "Research on Unified Data Model and Framework to Support Interoperability between IoT Applications"
o キム・ドンミョン、チェ・ユンチュル、ホン・ヨングン、「IoTアプリケーション間の相互運用性をサポートする統合データモデルとフレームワークに関する研究」
o Michael Koster, "Model-Based Hypertext Language"
o Michael Koster、「モデルベースのハイパーテキスト言語」
o Matthias Kovatsch, Yassin N. Hassan, and Klaus Hartke, "Semantic Interoperability Requires Self-describing Interaction Models"
o Matthias Kovatsch、Yassin N. Hassan、およびKlaus Hartke、「セマンティックインターオペラビリティには自己記述型相互作用モデルが必要」
o Kai Kreuzer, "A Pragmatic Approach to Interoperability in the Internet of Things"
o Kai Kreuzer、「モノのインターネットにおける相互運用性への実用的なアプローチ」
o Barry Leiba, "Position Paper"
o バリー・レイバ、「ポジションペーパー」
o Marcello Lioy, "AllJoyn"
o マルチェロ・リオイ、「オールジョイン」
o Kerry Lynn and Laird Dornin, "Modeling RESTful APIs with JSON Hyper-Schema"
o Kerry LynnとLaird Dornin、「JSON Hyper-Schemaを使用したRESTful APIのモデリング」
o Erik Nordmark, "Thoughts on IoT Semantic Interoperability: Scope of security issues"
o エリックノードマーク、「IoTセマンティック相互運用性に関する考え方：セキュリティ問題の範囲」
o Open Geospatial Consortium, "OGC SensorThings API: Communicating "Where" in the Web of Things"
o Open Geospatial Consortium、「OGC SensorThings API：Communicating "Where" in the Web of Things」
o Jean Paoli and Taqi Jaffri, "IoT Information Model Interoperability: An Open, Crowd-Sourced Approach in Three Parallel Parti"
o Jean PaoliとTaqi Jaffri、「IoT Information Model Interoperability：Open、Crowd-Sourced Approach in Three Parallel Parti」
o Joaquin Prado, "OMA Lightweight M2M Resource Model"
o Joaquin Prado、「OMA Lightweight M2M Resource Model」
o Dave Raggett and Soumya Kanti Datta, "Input paper for IAB Semantic Interoperability Workshop"
o Dave RaggettおよびSoumya Kanti Datta、「IAB Semantic Interoperability Workshopのインプットペーパー」
o Pete Rai and Stephen Tallamy, "Semantic Overlays Over Immutable Data to Facilitate Time and Context Specific Interoperability"
o ピートライとスティーブンタラミー「時間とコンテキスト固有の相互運用性を促進するための不変データのセマンティックオーバーレイ」
o Jasper Roes and Laura Daniele, "Towards semantic interoperability in the IoT using the Smart Appliances REFerence ontology (SAREF) and its extensions"
o Jasper RoesとLaura Daniele、「Smart Appliances REFerenceオントロジー（SAREF）とその拡張機能を使用して、IoTのセマンティック相互運用性に向けて」
o Max Senges, "Submission for IAB IoT Sematic Interoperability workshop"
o Max Senges、「IAB IoT Sematic Interoperability Workshopの提出」
o Bill Silverajan, Mert Ocak and Jaime Jimenez, "Implementation Experiences of Semantic Interoperability for RESTful Gateway Management"
o Bill Silverajan、Mert Ocak、Jaime Jimenez、「RESTfulゲートウェイ管理のためのセマンティック相互運用性の実装経験」
o Ned Smith, Jeff Sedayao, and Claire Vishik, "Key Semantic Interoperability Gaps in the Internet-of-Things Meta-Models"
o Ned Smith、Jeff Sedayao、およびClaire Vishik、「モノのインターネットメタモデルにおける重要なセマンティック相互運用性のギャップ」
o Robert Sparks and Ben Campbell, "Considerations for certain IoT-based services"
o Robert SparksおよびBen Campbell、「特定のIoTベースのサービスに関する考慮事項」
o J. Clarke Stevens, "Open Connectivity Foundation oneIoTa Tool"
o J.クラークスティーブンス、「Open Connectivity Foundation oneIoTa Tool」
o J. Clarke Stevens and Piper Merriam, "Derived Models for Interoperability Between IoT Ecosystems"
o J.クラークスティーブンスとパイパーメリアム、「IoTエコシステム間の相互運用性のための派生モデル」
o Ravi Subramaniam, "Semantic Interoperability in Open Connectivity Foundation (OCF) - formerly Open Interconnect Consortium (OIC)"
o Ravi Subramaniam、「Open Connectivity Foundation（OCF）-Semantic Interoperability in Open Connectivity Foundation（OCS）-以前はOpen Interconnect Consortium（OIC）」
o Andrew Sullivan, "Position paper for IOTSI workshop"
o アンドリューサリバン、「IOTSIワークショップのポジションペーパー」
o Darshak Thakore, "IoT Security in the context of Semantic Interoperability"
o Darshak Thakore、「セマンティック相互運用性のコンテキストにおけるIoTセキュリティ」
o Dave Thaler, "IoT Bridge Taxonomy"
o Dave Thaler、「IoT Bridge Taxonomy」
o Dave Thaler, "Summary of AllSeen Alliance Work Relevant to Semantic Interoperability"
o デイブ・ターラー、「セマンティック・インターオペラビリティーに関連するAllSeenアライアンス作業の要約」
o Mark Underwood, Michael Gruninger, Leo Obrst, Ken Baclawski, Mike Bennett, Gary Berg-Cross, Torsten Hahmann, and Ram Sriram, "Internet of Things: Toward Smart Networked Systems and Societies"
o Mark Underwood、Michael Gruninger、Leo Obrst、Ken Baclawski、Mike Bennett、Gary Berg-Cross、Torsten Hahmann、Ram Sriram、「モノのインターネット：スマートネットワークシステムと社会に向けて」
o Peter van der Stok and Andy Bierman, "YANG-Based Constrained Management Interface (CoMI)"
o Peter van der StokおよびAndy Bierman、「YANG-Based Constrained Management Interface（CoMI）」
Andy Bierman, YumaWorks Carsten Bormann, Uni Bremen/TZI Ben Campbell, Oracle Benoit Claise, Cisco Alissa Cooper, Cisco Robert Cragie, ARM Limited Laura Daniele, TNO Bryant Eastham, OpenDOF Christian Groves, Huawei Ted Hardie, Google Yonggeun Hong, ETRI Russ Housley, Vigil Security David Janes, IOTDB Jaime Jimenez, Ericsson Shailendra Karody, Catalina Labs Ari Keraenen, Ericsson Michael Koster, SmartThings Matthias Kovatsch, Siemens Kai Kreuzer, Deutsche Telekom Barry Leiba, Huawei Steve Liang, Uni Calgary Marcello Lioy, Qualcomm Kerry Lynn, Verizon Mayan Mathen, Catalina Labs Erik Nordmark, Arista Jean Paoli, Microsoft Joaquin Prado, OMA Dave Raggett, W3C Max Senges, Google Ned Smith, Intel Robert Sparks, Oracle Ram Sriram, NIST Clarke Stevens Ram Subramanian, Intel Andrew Sullivan, DIN Darshak Thakore, CableLabs Dave Thaler, Microsoft Hannes Tschofenig, ARM Limited Michael Verschoor, Philips Lighting
Andy Bierman、YumaWorks Carsten Bormann、Uni Bremen / TZI Ben Campbell、Oracle Benoit Claise、Cisco Alissa Cooper、Cisco Robert Cragie、ARM Limited Laura Daniele、TNO Bryant Eastham、OpenDOF Christian Groves、Huawei Ted Hardie、Google Yonggeun Hong、ETRI Russ Housley 、Vigil Security David Janes、IOTDB Jaime Jimenez、Ericsson Shailendra Karody、Catalina Labs Ari Keraenen、Ericsson Michael Koster、SmartThings Matthias Kovatsch、Siemens Kai Kreuzer、Deutsche Telekom Barry Leiba、Huawei Steve Liang、Uni Calgary Marcello Lioy、 Mayan Mathen、Catalina Labs Erik Nordmark、Arista Jean Paoli、Microsoft Joaquin Prado、OMA Dave Raggett、W3C Max Senges、Google Ned Smith、Intel Robert Sparks、Oracle Ram Sriram、NIST Clarke Stevens Ram Subramanian、Intel Andrew Sullivan、DIN Darshak Thakore、 CableLabs Dave Thaler、Microsoft Hannes Tschofenig、ARM Limited Michael Verschoor、Philips Lighting
IAB Members at the Time of Approval
承認時のIABメンバー
Jari Arkko Alissa Cooper Ted Hardie Christian Huitema Gabriel Montenegro Erik Nordmark Mark Nottingham Melinda Shore Robert Sparks Jeff Tantsura Martin Thomson Brian Trammell Suzanne Woolf
ヤリアルコアリッサクーパーテッドハーディクリスチャンウイテマガブリエルモンテネグロエリックノードマークマークノッティンガムメリンダショアロバートスパークスジェフタンツラマーティントムソンブライアントラメルスザンヌウルフ
Acknowledgements
謝辞
We would like to thank all paper authors and participants for their contributions and Ericsson for hosting the workshop.
ワークショップを主催してくれたすべての紙の著者と参加者、およびエリクソンに感謝します。
Authors' Addresses
著者のアドレス
Jaime Jimenez
ハイメ・ヒメネス
Email: jaime.jimenez@ericsson.com
Hannes Tschofenig
ハネス・チョフェニグ
Email: hannes.tschofenig@arm.com
Dave Thaler
デイブ・ターラー
Email: dthaler@microsoft.com