idnits 2.17.1
draft-johansson-netconf-owl-00.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
** It looks like you're using RFC 3978 boilerplate. You should update this
to the boilerplate described in the IETF Trust License Policy document
(see https://trustee.ietf.org/license-info), which is required now.
-- Found old boilerplate from RFC 3978, Section 5.1 on line 15.
-- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on
line 423.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 434.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 441.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 447.
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 Copyright Line does not match the
current year
-- The document seems to lack a disclaimer for pre-RFC5378 work, but may
have content which was first submitted before 10 November 2008. If you
have contacted all the original authors and they are all willing to grant
the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
this comment. If not, you may need to add the pre-RFC5378 disclaimer.
(See the Legal Provisions document at
https://trustee.ietf.org/license-info for more information.)
-- The document date (March 11, 2008) is 5890 days in the past. Is this
intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
== Unused Reference: 'RFC2119' is defined on line 376, but no explicit
reference was found in the text
== Outdated reference: A later version (-03) exists of
draft-presuhn-rcdml-00
Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 7 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Internet Engineering Task Force L. Johansson, Ed.
3 Internet-Draft Stockholm university
4 Intended status: Informational March 11, 2008
5 Expires: September 12, 2008
7 NETCONF Configuration Data Modeling using OWL
8 draft-johansson-netconf-owl-00
10 Status of this Memo
12 By submitting this Internet-Draft, each author represents that any
13 applicable patent or other IPR claims of which he or she is aware
14 have been or will be disclosed, and any of which he or she becomes
15 aware will be disclosed, in accordance with Section 6 of BCP 79.
17 Internet-Drafts are working documents of the Internet Engineering
18 Task Force (IETF), its areas, and its working groups. Note that
19 other groups may also distribute working documents as Internet-
20 Drafts.
22 Internet-Drafts are draft documents valid for a maximum of six months
23 and may be updated, replaced, or obsoleted by other documents at any
24 time. It is inappropriate to use Internet-Drafts as reference
25 material or to cite them other than as "work in progress."
27 The list of current Internet-Drafts can be accessed at
28 http://www.ietf.org/ietf/1id-abstracts.txt.
30 The list of Internet-Draft Shadow Directories can be accessed at
31 http://www.ietf.org/shadow.html.
33 This Internet-Draft will expire on September 12, 2008.
35 Copyright Notice
37 Copyright (C) The IETF Trust (2008).
39 Abstract
41 This document outlines an approach for a NETCONF data modeling
42 language based on the W3C Web Ontology Language (OWL).
44 Table of Contents
46 1. Introduction and Basic Terminology . . . . . . . . . . . . . . 3
47 2. Information modeling using OWL . . . . . . . . . . . . . . . . 3
48 3. Building protocols using OWL and RDF . . . . . . . . . . . . . 6
49 4. Advanced concepts . . . . . . . . . . . . . . . . . . . . . . 7
50 4.1. Your own RDF serialization . . . . . . . . . . . . . . . . 7
51 4.2. Versioning . . . . . . . . . . . . . . . . . . . . . . . . 7
52 5. NETCONF using OWL . . . . . . . . . . . . . . . . . . . . . . 8
53 5.1. Some of the NETCONF Requirements . . . . . . . . . . . . . 8
54 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
55 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
56 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
57 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
58 9.1. Normative References . . . . . . . . . . . . . . . . . . . 10
59 9.2. Informative References . . . . . . . . . . . . . . . . . . 10
60 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11
61 Intellectual Property and Copyright Statements . . . . . . . . . . 12
63 1. Introduction and Basic Terminology
65 The NETCONF working group has identified the need for a configuration
66 data modeling language . This document outlines an approach to
67 fulfill these requirements using the Web Ontology Laguage
68 [W3C.CR-owl-ref-20030818] (OWL). The OWL can be thought of as an
69 information modeling language with the expressive power of UML but
70 with a comparatively simple textual representation.
72 2. Information modeling using OWL
74 The Web Ontology Language (OWL) is a language for describing
75 information and models based on the Resource Description Framework
76 (RDF). Both RDF and OWL are W3C specifications. The OWL can be
77 thought of as the schema language for RDF-based data in much the same
78 way as LDAP schema is the modeling language describing LDAP-based
79 data.
81 A single OWL model (collection of OWL modeling elements) is called an
82 "ontology" and can be thought of as an OWL module. The OWL is
83 inherently extensible and has the expressive power of common modeling
84 languages like UML but with a much simpler textual representation of
85 models.
87 There are several existing implementations of OWL today all of which
88 support validation of OWL ontologies.
90 The OWL comes in three variants: OWL-Lite, OWL-DL and OWL-Full. A
91 complete description of the differences can be found in OWL Web
92 Ontology Language Guide [W3C.CR-owl-guide-20030818] section 1.1.
93 Most information modeling applications use OWL-DL which has enough
94 expressive power for most modeling needs while remaining relatively
95 easy to implement in modern programing languages. From the point of
96 view of a programmer OWL-DL can be viewed as a OO meta-model with
97 support for multiple inheritance: i.e there is a class concept and a
98 property (aka class member) concept. Classes have class members.
99 Class members (properties) has a domain and a range. The domain is a
100 class. The range is either a primitive type (all XML Schema types
101 are OWL primitive types) or another class.
103 The OWL is based on the Resource Description Framework
104 [W3C.PR-rdf-primer-20031215] (RDF) which provides the data
105 representation underlying both OWL and OWL class instances. This
106 means that an OWL schema (a collection of classes and properties) is
107 expressed as RDF as is any OWL class instance. In other words the
108 OWL is a "self hosting" extension of RDF. There are several ways to
109 represent RDF in textual form: N-Triples, N3 or RDF/XML any of which
110 is able to carry the full expressive power of OWL.
112 Before this gets too abstract we present a small example in the
113 approximate domain of NETCONF: the switch ontology, this time
114 represented using RDF/XML for the simple reason that this alternative
115 is by far the easiest to understand for the layman:
117
118
124
125
126 Example switch ontology
127
128
130
131
132
134
137
138
139
140
141
142
143 1
144
145
146
148
149
150
151
153
154
155
156
158
159
160
161
163
164 This example illustrates a few of the notable aspects of OWL as a
165 modeling tool. We have defined 4 classes - Port, PortCollection,
166 Layer2Element and Switch. A Switch inherits from both Layer2Element
167 and PortCollection and an anonymous class which restricts the port
168 attribute defined on PortCollection to having at least 1 port. In
169 plain English this means that a Switch is a Layer2Element and a
170 PortCollection with at least 1 port. In fact this sentence is a
171 reasonably good "English serialization" of the Switch model element.
172 This can be made more precise by studying the semantic foundations of
173 RDF and OWL.
175 The PortCollection can be thought of as an "abstract" class or
176 interface whereas the Switch is a concrete class which adds
177 specification details to both Layer2Element (which is included here
178 only to illustrate multiple inheritance) and PortCollection. Most
179 modern OO languages are easily able to build models from OWL meta-
180 models - i.e transform the meta-model given by an OWL schema into a
181 native model. This process is especially simple for languages which
182 natively support multiple inheritance in some form or another: eg
183 Ruby, Perl or Python but even more restrictive languages like Java
184 can easily emulate multiple inheritance through the use of the
185 factory/interface/implementation pattern.
187 3. Building protocols using OWL and RDF
189 In the same way that OWL can be used to model information it can be
190 used to model the representation of operations, if not their
191 semantics. This is analogous to using ASN.1 to model both protocol
192 elements and the objects operated upon by the protocol elements. The
193 result becomes inherently transport-neutral: anything which can send
194 messages using any of the serialiations of RDF can be used as the
195 transport of an OWL-based protocol.
197 The mental model to strive for is that the messages transported by a
198 "OWL-driven" protocol are RDF graphs - i.e structured data in RDF
199 form represented using some serialization of RDF (eg N-triples).
200 This graph may support several ontologies (eg multiple versions of
201 the sam protocol but we'll get back to that), i.e may express
202 relationships between individuals of multiple (possibly related) OWL
203 schema. By selecting (a set of) ontologies it is possible to create
204 a native object representation of the message.
206 +------------------------------------------+
207 | Object | Message abstraction |
208 +------------------------------------------+
209 | Ontology | Protocol description |
210 +------------------------------------------+
211 | RDF Graph | Protocol message |
212 +------------------------------------------+
214 This approach lends itself very well to implementation in modern
215 agile "duck-typed" programming languages but can also be done
216 (typically by employing code-generation) in strongly typed languages.
218 Naturally this isn't the first (or probably last) time a formal
219 language has been used to define information models and protocols
220 with varying results. One notable difference between OWL and related
221 efforts (eg ASN.1, XML Schema, Relax-NG, XDR) is that OWL has the
222 full expressive power of UML which means that there is little nead to
223 "dumb-down" the wire-representation of the objects modeled in the
224 application in order to meet the limitations of the interface
225 description language: i.e the application native information model
226 can be used more or less straight away as a basis for an OWL/RDF
227 model for the applications remoting needs.
229 4. Advanced concepts
231 4.1. Your own RDF serialization
233 Defining a new serialization of RDF is always an option if any of the
234 existing serializations are found to be lacking in some respects.
235 For instance it may be a good choice to use RDF/XML as a
236 serialization for protocol messages but the (lack of) readability of
237 XML may lead one to define a separate serialization for use when
238 defining ontologies for a given application.
240 As long as a full serialization is defined then almost all of the
241 drawbacks of defining a DSL (Domain Specific Language) are addressed
242 without adding too much complexity to a protocol definition or
243 information model.
245 4.2. Versioning
247 Managing multiple versions of the same information model can be
248 challenging. The OWL has a few constructs which helps with this job,
249 notably (again) multiple inheritance and the fact that an RDF graph
250 can support multiple ontologies concurrently. There are also owl
251 constructs such as the owl:equivalentProperty and owl:equivalentClass
252 relationships which allows one (version of) an ontology to be related
253 to another in a mashine-readable way.
255 5. NETCONF using OWL
257 The approach to using OWL as a basis for NETCONF configuration data
258 modeling would be to define a basic NETCONF ontology containing
259 concepts which are common to any NETCONF configuration model. Next
260 define ontologies for NETCONF operations and NETCONF notifications
261 (as identified in the requirements) and finally agree on standard RDF
262 serialiations for NETCONF models - eg use RDF/XML always or use RDF/
263 XML for protocol messages and a custom serialization (to be defined)
264 for NETCONF models.
266 5.1. Some of the NETCONF Requirements
268 This is not an exhaustive treatise of the list of requirements found
269 in [NETCONFREQS] but rather an attempt to single out the requirements
270 where the choice of OWL has a signifficant impact
272 3.1.1 - Notification Definitions. By definiting a NETCONF
273 notification ontology.
275 3.1.4 - All Base Operations. By defining a NETCONF operations
276 ontology and related semantics.
278 3.1.5 - Define new NETCONF Operations. Define another NETCONF
279 operations ontology extending the base NETCONF operations
280 ontology.
282 3.1.5 - Separation of Operations and Payload. Even if OWL is
283 expressed in RDF and OWL ontologies are by definition valid RDF
284 this won't cause any confusion, mainly because we have limited
285 ourselves to OWL-DL where there is a clear separation between
286 model elements and instances.
288 3.1.7 - Error Annotation. Multiple inheritance allows one to tie
289 annontations in any form to any model element simply by making
290 everything that needs annotation inherit from an annotation class.
292 3.2.1 - Human Readable. Arguably humans can read RDF. If a
293 counter-example is produced then a custom RDF serialiation may be
294 in order.
296 3.2.4 - Document Information. Ontologies have metadata natively -
297 RDF is after all a metadata representation mechanism.
299 3.2.5 - Ownership and Change Control. Everything in RDF is
300 identified using URIs, including the ontologies themselves.
301 Ownership and Change control is exercised via control over the
302 namespaces involved.
304 3.2.6 - Dependency Risk Reduction. The version of OWL and RDF
305 used in an ontology are referenced explicitly by default.
307 3.2.8 - Internationaliation and Localization. All RDF literals
308 are language-tagged by default.
310 3.3 - Resusability Requirements. OWL by construction is modular.
311 References between OWL ontologies (modules) are the norm.
313 3.4.3 - Validation. Validation of RDF against an OWL schema is
314 readily available. Tools for validation of OWL schema can be
315 readily found on the Internet.
317 3.5.1 - Human-Readable Semantics. RDF is based on the notion of
318 statements of the form subject relation object which can be
319 spelled out as propostitions of the form "Something has relation X
320 to Something else". This makes it almost an automatic process to
321 produce a plain text version of an ontology even if readability
322 may require extra effort. Apart from that the standard
323 documentation constructs built into OWL provide means to include
324 documentation in the ontology.
326 3.5.2 - Basic Types. All XML Schema types are primitive types of
327 OWL
329 3.5.3 - Opaque Data. The owl:Thing class is the superclass of all
330 classes. Properties with range owl:Thing are essentially defining
331 opaque data properties of a class.
333 3.5.4 - Keys. Each object in an RDF graph is uniquely identified
334 by its URI. The concept of a key is not native to RDF but can be
335 easily represented in OWL either by using the owl:
336 InverseFunctionalProperty to declare a property unique or by
337 defining a class whose properties are the (compound) key of any
338 superclass of that key-class.
340 3.5.5 - Relationships. OWL supports all types of relationships
341 1:1, 1:n, or m:n. Since all relationships in OWL use URIs as
342 identifiers there is no ambiguity when resolving relationship
343 identifiers
345 3.5.8 - Characterize Data. Define two classes - ConfigurtionData,
346 StatusData with no properties, these classes act as markes on
347 classes allowing an implementation to make the destinction.
349 3.5.10 - Formal Constraints. Support for most of these
350 requirements are either native or can be implemented in the model.
352 3.6.1 - Language extensibility. OWL is versioned and expressed in
353 terms of RDF it is quite possible to extend both RDF and OWL.
355 3.6.2 - Model Extensibility. OWL has native constructs which can
356 be used to express how one model extends, imports and is
357 compatible with another model. This also applies in part to 3.6.3
359 3.6.3 - Instance Data Extensibility. Since the ontology URI is
360 normally part of (as the base URI of) the URIs of the model
361 elements in the ontology it is easy to include ontology version
362 informaiton in all types.
364 6. Acknowledgements
366 7. IANA Considerations
368 This memo includes no request to IANA.
370 8. Security Considerations
372 9. References
374 9.1. Normative References
376 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
377 Requirement Levels", BCP 14, RFC 2119, March 1997.
379 9.2. Informative References
381 [NETCONFREQS]
382 "Requirements for a Configuration Data Modeling Language",
383 .
386 [W3C.CR-owl-guide-20030818]
387 Smith, M., Welty, C., and D. McGuinness, "OWL Web Ontology
388 Language Guide", W3C CR CR-owl-guide-20030818,
389 August 2003.
391 [W3C.CR-owl-ref-20030818]
392 Dean, M. and G. Schreiber, "OWL Web Ontology Language
393 Reference", W3C CR CR-owl-ref-20030818, August 2003.
395 [W3C.PR-rdf-primer-20031215]
396 Manola, F. and E. Miller, "RDF Primer", W3C PR PR-rdf-
397 primer-20031215, December 2003.
399 Author's Address
401 Leif Johansson (editor)
402 Stockholm university
403 Stockholm, SE-10691
404 Sweden
406 Phone: +46 8 162000
407 Email: leifj@it.su.se
409 Full Copyright Statement
411 Copyright (C) The IETF Trust (2008).
413 This document is subject to the rights, licenses and restrictions
414 contained in BCP 78, and except as set forth therein, the authors
415 retain all their rights.
417 This document and the information contained herein are provided on an
418 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
419 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
420 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
421 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
422 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
423 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
425 Intellectual Property
427 The IETF takes no position regarding the validity or scope of any
428 Intellectual Property Rights or other rights that might be claimed to
429 pertain to the implementation or use of the technology described in
430 this document or the extent to which any license under such rights
431 might or might not be available; nor does it represent that it has
432 made any independent effort to identify any such rights. Information
433 on the procedures with respect to rights in RFC documents can be
434 found in BCP 78 and BCP 79.
436 Copies of IPR disclosures made to the IETF Secretariat and any
437 assurances of licenses to be made available, or the result of an
438 attempt made to obtain a general license or permission for the use of
439 such proprietary rights by implementers or users of this
440 specification can be obtained from the IETF on-line IPR repository at
441 http://www.ietf.org/ipr.
443 The IETF invites any interested party to bring to its attention any
444 copyrights, patents or patent applications, or other proprietary
445 rights that may cover technology that may be required to implement
446 this standard. Please address the information to the IETF at
447 ietf-ipr@ietf.org.
449 Acknowledgment
451 Funding for the RFC Editor function is provided by the IETF
452 Administrative Support Activity (IASA).