Internet Engineering Task Force L. Johansson, Ed. Internet-Draft Stockholm university Intended status: Informational March 11, 2008 Expires: September 12, 2008 NETCONF Configuration Data Modeling using OWL draft-johansson-netconf-owl-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on September 12, 2008. Copyright Notice Copyright (C) The IETF Trust (2008). Abstract This document outlines an approach for a NETCONF data modeling language based on the W3C Web Ontology Language (OWL). Johansson Expires September 12, 2008 [Page 1] Internet-Draft NETCONF OWL March 2008 Table of Contents 1. Introduction and Basic Terminology . . . . . . . . . . . . . . 3 2. Information modeling using OWL . . . . . . . . . . . . . . . . 3 3. Building protocols using OWL and RDF . . . . . . . . . . . . . 6 4. Advanced concepts . . . . . . . . . . . . . . . . . . . . . . 7 4.1. Your own RDF serialization . . . . . . . . . . . . . . . . 7 4.2. Versioning . . . . . . . . . . . . . . . . . . . . . . . . 7 5. NETCONF using OWL . . . . . . . . . . . . . . . . . . . . . . 8 5.1. Some of the NETCONF Requirements . . . . . . . . . . . . . 8 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 9.1. Normative References . . . . . . . . . . . . . . . . . . . 10 9.2. Informative References . . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 Intellectual Property and Copyright Statements . . . . . . . . . . 12 Johansson Expires September 12, 2008 [Page 2] Internet-Draft NETCONF OWL March 2008 1. Introduction and Basic Terminology The NETCONF working group has identified the need for a configuration data modeling language . This document outlines an approach to fulfill these requirements using the Web Ontology Laguage [W3C.CR-owl-ref-20030818] (OWL). The OWL can be thought of as an information modeling language with the expressive power of UML but with a comparatively simple textual representation. 2. Information modeling using OWL The Web Ontology Language (OWL) is a language for describing information and models based on the Resource Description Framework (RDF). Both RDF and OWL are W3C specifications. The OWL can be thought of as the schema language for RDF-based data in much the same way as LDAP schema is the modeling language describing LDAP-based data. A single OWL model (collection of OWL modeling elements) is called an "ontology" and can be thought of as an OWL module. The OWL is inherently extensible and has the expressive power of common modeling languages like UML but with a much simpler textual representation of models. There are several existing implementations of OWL today all of which support validation of OWL ontologies. The OWL comes in three variants: OWL-Lite, OWL-DL and OWL-Full. A complete description of the differences can be found in OWL Web Ontology Language Guide [W3C.CR-owl-guide-20030818] section 1.1. Most information modeling applications use OWL-DL which has enough expressive power for most modeling needs while remaining relatively easy to implement in modern programing languages. From the point of view of a programmer OWL-DL can be viewed as a OO meta-model with support for multiple inheritance: i.e there is a class concept and a property (aka class member) concept. Classes have class members. Class members (properties) has a domain and a range. The domain is a class. The range is either a primitive type (all XML Schema types are OWL primitive types) or another class. The OWL is based on the Resource Description Framework [W3C.PR-rdf-primer-20031215] (RDF) which provides the data representation underlying both OWL and OWL class instances. This means that an OWL schema (a collection of classes and properties) is expressed as RDF as is any OWL class instance. In other words the OWL is a "self hosting" extension of RDF. There are several ways to represent RDF in textual form: N-Triples, N3 or RDF/XML any of which Johansson Expires September 12, 2008 [Page 3] Internet-Draft NETCONF OWL March 2008 is able to carry the full expressive power of OWL. Before this gets too abstract we present a small example in the approximate domain of NETCONF: the switch ontology, this time represented using RDF/XML for the simple reason that this alternative is by far the easiest to understand for the layman: Johansson Expires September 12, 2008 [Page 4] Internet-Draft NETCONF OWL March 2008 Example switch ontology 1 Johansson Expires September 12, 2008 [Page 5] Internet-Draft NETCONF OWL March 2008 This example illustrates a few of the notable aspects of OWL as a modeling tool. We have defined 4 classes - Port, PortCollection, Layer2Element and Switch. A Switch inherits from both Layer2Element and PortCollection and an anonymous class which restricts the port attribute defined on PortCollection to having at least 1 port. In plain English this means that a Switch is a Layer2Element and a PortCollection with at least 1 port. In fact this sentence is a reasonably good "English serialization" of the Switch model element. This can be made more precise by studying the semantic foundations of RDF and OWL. The PortCollection can be thought of as an "abstract" class or interface whereas the Switch is a concrete class which adds specification details to both Layer2Element (which is included here only to illustrate multiple inheritance) and PortCollection. Most modern OO languages are easily able to build models from OWL meta- models - i.e transform the meta-model given by an OWL schema into a native model. This process is especially simple for languages which natively support multiple inheritance in some form or another: eg Ruby, Perl or Python but even more restrictive languages like Java can easily emulate multiple inheritance through the use of the factory/interface/implementation pattern. 3. Building protocols using OWL and RDF In the same way that OWL can be used to model information it can be used to model the representation of operations, if not their semantics. This is analogous to using ASN.1 to model both protocol elements and the objects operated upon by the protocol elements. The result becomes inherently transport-neutral: anything which can send messages using any of the serialiations of RDF can be used as the transport of an OWL-based protocol. The mental model to strive for is that the messages transported by a "OWL-driven" protocol are RDF graphs - i.e structured data in RDF form represented using some serialization of RDF (eg N-triples). This graph may support several ontologies (eg multiple versions of the sam protocol but we'll get back to that), i.e may express relationships between individuals of multiple (possibly related) OWL schema. By selecting (a set of) ontologies it is possible to create a native object representation of the message. Johansson Expires September 12, 2008 [Page 6] Internet-Draft NETCONF OWL March 2008 +------------------------------------------+ | Object | Message abstraction | +------------------------------------------+ | Ontology | Protocol description | +------------------------------------------+ | RDF Graph | Protocol message | +------------------------------------------+ This approach lends itself very well to implementation in modern agile "duck-typed" programming languages but can also be done (typically by employing code-generation) in strongly typed languages. Naturally this isn't the first (or probably last) time a formal language has been used to define information models and protocols with varying results. One notable difference between OWL and related efforts (eg ASN.1, XML Schema, Relax-NG, XDR) is that OWL has the full expressive power of UML which means that there is little nead to "dumb-down" the wire-representation of the objects modeled in the application in order to meet the limitations of the interface description language: i.e the application native information model can be used more or less straight away as a basis for an OWL/RDF model for the applications remoting needs. 4. Advanced concepts 4.1. Your own RDF serialization Defining a new serialization of RDF is always an option if any of the existing serializations are found to be lacking in some respects. For instance it may be a good choice to use RDF/XML as a serialization for protocol messages but the (lack of) readability of XML may lead one to define a separate serialization for use when defining ontologies for a given application. As long as a full serialization is defined then almost all of the drawbacks of defining a DSL (Domain Specific Language) are addressed without adding too much complexity to a protocol definition or information model. 4.2. Versioning Managing multiple versions of the same information model can be challenging. The OWL has a few constructs which helps with this job, notably (again) multiple inheritance and the fact that an RDF graph can support multiple ontologies concurrently. There are also owl constructs such as the owl:equivalentProperty and owl:equivalentClass Johansson Expires September 12, 2008 [Page 7] Internet-Draft NETCONF OWL March 2008 relationships which allows one (version of) an ontology to be related to another in a mashine-readable way. 5. NETCONF using OWL The approach to using OWL as a basis for NETCONF configuration data modeling would be to define a basic NETCONF ontology containing concepts which are common to any NETCONF configuration model. Next define ontologies for NETCONF operations and NETCONF notifications (as identified in the requirements) and finally agree on standard RDF serialiations for NETCONF models - eg use RDF/XML always or use RDF/ XML for protocol messages and a custom serialization (to be defined) for NETCONF models. 5.1. Some of the NETCONF Requirements This is not an exhaustive treatise of the list of requirements found in [NETCONFREQS] but rather an attempt to single out the requirements where the choice of OWL has a signifficant impact 3.1.1 - Notification Definitions. By definiting a NETCONF notification ontology. 3.1.4 - All Base Operations. By defining a NETCONF operations ontology and related semantics. 3.1.5 - Define new NETCONF Operations. Define another NETCONF operations ontology extending the base NETCONF operations ontology. 3.1.5 - Separation of Operations and Payload. Even if OWL is expressed in RDF and OWL ontologies are by definition valid RDF this won't cause any confusion, mainly because we have limited ourselves to OWL-DL where there is a clear separation between model elements and instances. 3.1.7 - Error Annotation. Multiple inheritance allows one to tie annontations in any form to any model element simply by making everything that needs annotation inherit from an annotation class. 3.2.1 - Human Readable. Arguably humans can read RDF. If a counter-example is produced then a custom RDF serialiation may be in order. 3.2.4 - Document Information. Ontologies have metadata natively - RDF is after all a metadata representation mechanism. Johansson Expires September 12, 2008 [Page 8] Internet-Draft NETCONF OWL March 2008 3.2.5 - Ownership and Change Control. Everything in RDF is identified using URIs, including the ontologies themselves. Ownership and Change control is exercised via control over the namespaces involved. 3.2.6 - Dependency Risk Reduction. The version of OWL and RDF used in an ontology are referenced explicitly by default. 3.2.8 - Internationaliation and Localization. All RDF literals are language-tagged by default. 3.3 - Resusability Requirements. OWL by construction is modular. References between OWL ontologies (modules) are the norm. 3.4.3 - Validation. Validation of RDF against an OWL schema is readily available. Tools for validation of OWL schema can be readily found on the Internet. 3.5.1 - Human-Readable Semantics. RDF is based on the notion of statements of the form subject relation object which can be spelled out as propostitions of the form "Something has relation X to Something else". This makes it almost an automatic process to produce a plain text version of an ontology even if readability may require extra effort. Apart from that the standard documentation constructs built into OWL provide means to include documentation in the ontology. 3.5.2 - Basic Types. All XML Schema types are primitive types of OWL 3.5.3 - Opaque Data. The owl:Thing class is the superclass of all classes. Properties with range owl:Thing are essentially defining opaque data properties of a class. 3.5.4 - Keys. Each object in an RDF graph is uniquely identified by its URI. The concept of a key is not native to RDF but can be easily represented in OWL either by using the owl: InverseFunctionalProperty to declare a property unique or by defining a class whose properties are the (compound) key of any superclass of that key-class. 3.5.5 - Relationships. OWL supports all types of relationships 1:1, 1:n, or m:n. Since all relationships in OWL use URIs as identifiers there is no ambiguity when resolving relationship identifiers 3.5.8 - Characterize Data. Define two classes - ConfigurtionData, StatusData with no properties, these classes act as markes on Johansson Expires September 12, 2008 [Page 9] Internet-Draft NETCONF OWL March 2008 classes allowing an implementation to make the destinction. 3.5.10 - Formal Constraints. Support for most of these requirements are either native or can be implemented in the model. 3.6.1 - Language extensibility. OWL is versioned and expressed in terms of RDF it is quite possible to extend both RDF and OWL. 3.6.2 - Model Extensibility. OWL has native constructs which can be used to express how one model extends, imports and is compatible with another model. This also applies in part to 3.6.3 3.6.3 - Instance Data Extensibility. Since the ontology URI is normally part of (as the base URI of) the URIs of the model elements in the ontology it is easy to include ontology version informaiton in all types. 6. Acknowledgements 7. IANA Considerations This memo includes no request to IANA. 8. Security Considerations 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 9.2. Informative References [NETCONFREQS] "Requirements for a Configuration Data Modeling Language", . [W3C.CR-owl-guide-20030818] Smith, M., Welty, C., and D. McGuinness, "OWL Web Ontology Language Guide", W3C CR CR-owl-guide-20030818, August 2003. Johansson Expires September 12, 2008 [Page 10] Internet-Draft NETCONF OWL March 2008 [W3C.CR-owl-ref-20030818] Dean, M. and G. Schreiber, "OWL Web Ontology Language Reference", W3C CR CR-owl-ref-20030818, August 2003. [W3C.PR-rdf-primer-20031215] Manola, F. and E. Miller, "RDF Primer", W3C PR PR-rdf- primer-20031215, December 2003. Author's Address Leif Johansson (editor) Stockholm university Stockholm, SE-10691 Sweden Phone: +46 8 162000 Email: leifj@it.su.se Johansson Expires September 12, 2008 [Page 11] Internet-Draft NETCONF OWL March 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Johansson Expires September 12, 2008 [Page 12]