idnits 2.17.1 draft-strassner-t2trg-semantics-and-iot-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 8, 2016) is 2970 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-05) exists of draft-strassner-supa-generic-policy-info-model-04 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Thing-to-Thing Research Group J. Strassner 2 Internet-Draft Huawei Technologies 3 Intended Status: Informational J. Halpern 4 Expires: September 12, 2016 Ericsson 5 Q. Wu 6 Huawei Technologies 7 March 8, 2016 9 Semantics and the Internet of Things 10 draft-strassner-t2trg-semantics-and-iot-00 12 Abstract 14 This document examines how semantics help different deployments in 15 an Internet of Things (IoT) environment interoperate. IoT data, 16 device, and system interoperability requires semantics to ensure 17 that the meaning of terms and objects in one device or system are 18 not lost or altered when they are exchanged and used by other 19 devices or systems. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six 32 months and may be updated, replaced, or obsoleted by other documents 33 at any time. It is inappropriate to use Internet-Drafts as 34 reference material or to cite them other than as "work in progress". 36 This Internet-Draft will expire on September 12, 2016. 38 Copyright Notice 40 Copyright (c) 2016 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with 48 respect to this document. Code Components extracted from this 49 document must include Simplified BSD License text as described in 50 Section 4.e of the Trust Legal Provisions and are provided without 51 warranty as described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction and Motivation ................................. 2 56 2. Why Information and Data Models Alone Are Not Enough ........ 2 57 3. Why Ontologies Alone Are Not Enough ......................... 3 58 4. A Proposed Architectural Solution ........................... 4 59 5. Future Issues ............................................... 6 60 6. Security Considerations ..................................... 6 61 7. IANA Considerations ......................................... 6 62 8. References .................................................. 6 63 Authors' Addresses .............................................. 7 65 1. Introduction and Motivation 67 The Internet of Things (IoT) includes a wide range of devices with 68 a diverse set of functionality. This ranges from "smart" devices [1] 69 [2] to simple sensors and actuators that lack any ability to deviate 70 from their pre-programmed functions. 72 The IoT is currently being populated by diverse devices and systems 73 that are operating as silos. A unified, open system that can support 74 multiple applications cannot be built in a "bottom-up" fashion; this 75 simply encourages more silos. Since different devices will have very 76 different capabilities, standard networking assumptions (e.g., the 77 ability to connect to the Internet anytime) are not applicable. The 78 IoT operates more as a collection of consumers and providers of data 79 than as a typical point-to-point communication system. 81 2. Why Information and Data Models Alone Are Not Enough 83 An information model (IM) [3] defines a common set of terminology 84 and manageable objects. IMs can be used to define disparate data 85 models (DMs), and maintain coherence between each realization of 86 each common term in each DM. However, IMs and DMs by themselves 87 CANNOT guarantee semantic interoperability. 89 Semantics in IMs are largely defined by the **descriptive** text 90 associated with the model, rather than by any **formal elements** 91 contained in the model. This leads to several limitations. First and 92 foremost, it is hard, even for human beings, to determine when two 93 IMs are describing the same concept. This is due to several reasons, 94 including expressing one concept as a set of model elements, having 95 a large number of model elements to understand, and because of the 96 inherent ambiguity of using descriptive, rather than formal, 97 definitions of the model elements. Doing so in an automatic and 98 scalable fashion to support dynamic creation of devices is **much** 99 harder. Models define objects, facts, and values (i.e., data with 100 no persistence) in an extensible manner. However, without formal 101 semantics, reasoning (e.g., subsumption, as used in OWL [16]) is 102 precluded. 104 To complete the picture, it should be noted that DMs without IMs are 105 even more limiting. Trying for conceptual alignment and reasoning 106 across different data modeling techniques is almost impossible, 107 particularly due to the inability of many DMs to express the rich 108 semantics required by IoT interoperability. 110 3. Why Ontologies Alone Are Not Enough 112 An ontology [4] [5] for a given domain defines a set of formulae 113 that represent the characteristics and behavior of entities in that 114 domain. Ontologies, unlike IMs, use **formal** languages (typically, 115 either first-order logic or some type of description logic); this 116 helps remove ambiguities that can creep into an IM or a DM. However, 117 using ontologies as the sole source of information also has a number 118 of problems. 120 First, ontologies use an Open World Assumption (OWA), while IMs and 121 DMs use a Closed World Assumption (CWA). An OWA means that the truth 122 of a statement is independent of whether or not it is known to be 123 true. In contrast, a CWA means that if a statement is true, then it 124 is also known to be true. Significantly, this means that if something 125 is not known to be true, then it is false. Put another way, OWA 126 means that the lack of knowledge does NOT imply falsity. This is a 127 key characteristic for enabling inferencing to create new knowledge 128 from existing knowledge. 130 Second, ontologies focus on the runtime exploitation of knowledge 131 [14], while IMs and DMs are used for realization of knowledge. IMs 132 and DMs provide answers in the form of facts. This is often much 133 simpler than applying logic to reason about whether a particular 134 attribute has a given value or not. Note that if models are 135 augmented with metadata, then the metadata may be used to "wrap" 136 objects together at runtime, making it possible to add behavior 137 and/or attributes to models at runtime. See, for example, section 138 5.7 of [15] for how this is used in an IETF IM. 140 Third, ontologies become less suitable compared to IMs and DMs when 141 the concepts to be represented do not have precise definitions. 142 While work on using different forms of multiple-valued logic (e.g., 143 fuzzy logic, which is different than probability) have been applied 144 to both IMs/DMs and ontologies, in all cases known to the authors, 145 this requires manual coding of relationships and formulae, as well 146 as manual definition of the type of logic used, and how it is 147 extended to include fuzzy reasoning. Furthermore, no standard 148 reasoners that allow the user to define their own type of fuzzy 149 logic are available. 151 Fourth, networks are inherently collections of heterogeneous 152 entities. Their context and topology change, which causes their 153 behavior to change. This is very difficult to model using 154 ontologies, and typically leads to unsolvable complexity problems. 156 Finally, the vast majority of equipment data are defined using DMs, 157 which are difficult to translate into ontologies. First, notions of 158 methods, which frequently appear on classes in models, do not have 159 a direct counterpart in ontologies. Classes in models emphasize the 160 operational properties of the object; classes in ontologies reflect 161 the structural properties of the object. We need to incorporate the 162 formal reasoning power of ontologies **without breaking our current 163 uses of DMs**. 165 4. A Proposed Architectural Solution 167 The FOCALE architecture, first defined in [6], combined the use of 168 models and ontologies to build a scalable and extensible knowledge 169 base. Information and data models were used to represent facts, and 170 ontologies were used to represent the semantics required to reason 171 about those facts. The combination of models and ontologies served 172 to deal with the inherent cognitive dissonance that arises from 173 heterogeneous data generated by different platforms, languages, and 174 protocols. For example, models can be used to represent different 175 telemetry data generated by IoT devices, and ontologies can be used 176 to relate these data using one or more semantic relationships (e.g., 177 is-similar-to, is-identical-to, as well as more traditional 178 linguistic relationships, such as synonyms, antonyms, and 179 meronyms). The semantic processing engine can then use reasoning to 180 determine and infer relationships between data, structures of data, 181 and recognize new data (i.e., data that has not been defined). 183 In FOCALE, we used the standard Data-Information-Knowledge-Wisdom 184 (DIKW) [7] approach to discover and annotate data. We consider DIKW 185 a continuum; as more information is collected, DIKW elements do not 186 "disappear", but instead are augmented/enhanced, and can move up the 187 continuum. This enables a number of breakthroughs [8], including: 189 o heterogeneous data can be recognized as being similar 190 o different commands using different languages can be normalized 191 o incorrect knowledge can be corrected, and new knowledge can be 192 added to the knowledge base 194 FOCALE is a variant of Model-Driven Engineering (MDE) [9]. MDE uses 195 an integrated view to more directly translate design intent into 196 implementation through the use of software tooling. Key to such 197 tooling are metadata, Domain-Specific Languages (DSLs), and MDE 198 architectures. 200 Metadata has been defined as data about data. In MDE, metadata is 201 descriptive and/or prescriptive information about concepts that are 202 not limited to data, but can apply to any managed object. This has 203 been used in industries (though not necessarily networking related) 204 for a long time. For example, the Force.com platform is a metadata- 205 driven development model [10]. 207 Metadata enables all deployment and non-functional behavior for 208 different applications to be derived from the same model and 209 automatically generate configuration and monitoring information. 210 See sections 5.16 - 5.20 of [15] for how this is used in an IETF IM. 212 APIs are a hot topic. However, an API is just a static definition, 213 at a particular point in time, of some functionality. What happens 214 if that functionality changes? The API breaks. What is the context 215 in which the API is being used changes? The API may no longer be 216 applicable. Relying on just APIs makes a software design fragile. 217 Instead, if APIs and the data that they use are annotated with 218 appropriate metadata, they can transform application-specific data 219 into a common form used by other applications. Metadata, when used 220 with models and ontologies, creates a self-describing framework that 221 enables data to define contextually-aware application features and 222 functionality. Such an architecture is needed for IoT, because IoT 223 data does not conform to one "universal schema". In addition, IoT 224 data needs metadata augmentation as a first step to define and 225 understand the hidden semantics that are associated with IoT data. 227 The underlying issues with IoT are not its volume and velocity, but 228 rather how to extract **value** from collected and processed IoT 229 data [17]. The solution proposed in [17] discovers, through machine- 230 based reasoning, semantic information describing ingested data as 231 well as the context in which the data is produced and received, and 232 then annotates the data using a number of mechanisms, such as [18]. 234 Domain Specific Languages (DSLs) provide a robust way to implement 235 specific configuration and monitoring processes by being formed 236 from models and ontologies that contain metadata [11]. Briefly, the 237 combination of a model and an ontology can be used to represent the 238 syntax and semantics of a grammar (for the DSL). This approach 239 provides an extensible vocabulary, and associated lexicon, for the 240 grammar. When used in an MDE environment, the grammar may be 241 dynamically refined and adjusted to address the needs of the users 242 of the DSL. 244 [11] uses this approach, along with the concept of the Policy 245 Continuum [19], to define a set of DSLs for different constituencies 246 of users. The Policy Continuum posits that different actors, ranging 247 from business users and product managers, to application developers, 248 to network, compute, and storage administrators, all use policy 249 rules; however, the policy used by each of these actors is different 250 in terms of structure, content, and representation. Writing multiple 251 different languages, with the intent of having them interoperate, is 252 very difficult. In contrast, this approach defines a single 253 conceptual grammar, and then takes pieces of the grammar to build 254 "mini-languages" (i.e., DSLs), each focused on the needs of a 255 specific set of actors. Significantly, this means that changes in 256 the data model can be transformed to a common representation in the 257 information model, which can then be translated into changes in one 258 or more DSLs. Optionally, APIs can also be defined. 260 5. Future Issues 262 There are a number of future issues that need to be worked. These 263 include, but are not limited to: 265 o how to harness the enormous repository of Linked Open Data [12] 266 on the web, and to extract useful data for IoT applications, or 267 whether Linked Open Data is "merely more data" [13] 268 o how to standardize IM to DM mappings/transformations 269 o how to standardize adding and managing metadata with IoT data 270 o how to develop new architectural patterns for IoT data 271 processing that lend themselves to Big Data and Analytics 272 o how different policy paradigms (e.g., imperative and intent- 273 based, or declarative) can be supported 275 6. Security Considerations 277 TBD 279 7. IANA Considerations 281 This document has no actions for IANA. 283 8. References 285 8.1. Informative References 287 [1] G. Kortuem, F. Kawsar, V. Sundramoorthy, D. Fitton, "Smart 288 objects as building blocks for the internet of things", 289 IEEE Internet Comput. 14 (2010), pp 44-51 290 [2] Horizon 2020 Work Programme 2014-2015, ICT 30 - 2015: 291 "Internet of Things and Platforms for Connected Smart Objects" 292 amended April 17, 2015 294 [3] A. Pras, J. Schoenwaelder, "On the Difference between 295 Information Models and Data Models", RFC 3444, January 2003 296 [4] N. F. Noy, D. L. McGuinness, "Ontology Development 101: A 297 Guide to Creating Your First Ontology", Stanford Knowledge 298 Systems Laboratory Technical Report KSL-01-05, March 2001. 299 [5] S. Staab, R. Studer, "Handbook on Ontologies", Springer, 2nd 300 edition, 2009, ISBN: 978-3540709992 301 [6] J. Strassner, N. Agoulmine, E. Lehtihet, "FOCALE - A Novel 302 Autonomic Networking Architecture", International Transactions 303 on Systems, Science, and Applications Journal, vol 3, No 1, 304 pp 64-79, 2007 305 [7] J. Rowley, "The wisdom hierarchy: representations of the DIKW 306 hierarchy", Journal of Information Science 33, pp 163-180, 2007 308 [8] J. Strassner, S. van der Meer, D. O'Sullivan, S. Dobson, "The 309 Use of Context-Aware Policies and Ontologies to Facilitate 310 Business-Aware Network Management", Journal of Network and 311 System Management 17, pp 255-284, 2009 312 [9] D. C. Schmidt, "Model-Driven Engineering", IEEE Computer 2006 313 [10] https://developer.salesforce.com/docs/atlas.en-us. 314 fundamentals.meta/fundamentals/adg_intro_metadata.htm 315 [11] J. Strassner, "Model-driven DSLs", work in progress 316 [12] B. Haslhofer, "Linked Data Tutorial", 2009 317 http://www.slideshare.net/bhaslhofer/linked-data-tutorial 318 [13] P. Jain, P. Hitler, P.Z. Yeh, K. Verma, A.P. Sheth, "Linked 319 Data is Merely More Data", Proc. WWW 2009 Workhop on Linked 320 Data on the Web, 2009 321 [14] W3C, "Ontology Driven Architectures and Potential Uses of the 322 Semantic Web in Systems and Software Engineering", 2006 323 [15] J. Strassner, J. Halpern, J. Coleman, "Generic Policy 324 Information Model for Simplified Use of Policy Abstractions 325 (SUPA)", draft-strassner-supa-generic-policy-info-model-04, 326 Feb 12, 2016 327 [16] W3C, "OWL 2 Web Ontology Language Document Overview (Second 328 Edition)", W3C Recommendation, 11 Dec 2012 329 https://www.w3.org/TR/owl2-overview/ 330 [17] J. Strassner, "Engineering Value from Big Data", presentation 331 at the First International Workshop for Big Data Standards, 332 March 7, 2016 333 [18] W3c, "RDFa 1.1 Primer - Third Edition", W3C Working Group 334 Note, March 17, 2015, https://www.w3.org/TR/xhtml-rdfa-primer/ 335 [19] S. Davy, B. Jennings, J. Strassner, "The Policy Continuum - A 336 Formal Model", Proc. of the 2nd Intl. IEEE Workshop on 337 Modeling Autonomic Communication Environments (MACE), Multicon 338 Lecture Notes, No. 6, Multicon, Berlin, 2007, pages 65-78 340 Authors' Addresses 342 John Strassner 343 Huawei Technologies 344 2230 Central Expressway 345 San Jose, CA USA 346 Email: john.sc.strassner@huawei.com 348 Joel Halpern 349 Ericsson 350 P. O. Box 6049 351 Leesburg, VA 20178 352 Email: joel.halpern@ericsson.com 354 Qin Wu 355 Huawei Technologies 356 101 Software Avenue, Yuhua District 357 Nanjing, Jiangsu 210012 China 358 Email: bill.wu@huawei.com