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
<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
xmlns:owl="http://www.w3.org/2002/07/owl#"
xmlns="http://www.ietf.org/netconf/switch/#"
xml:base="http://www.ietf.org/netconf/switch/#">
<owl:Ontology>
<rdfs:comment>
Example switch ontology
</rdfs:comment>
</owl:Ontology>
<owl:Class rdf:ID="Port"/>
<owl:Class rdf:ID="PortCollection"/>
<owl:Class rdf:ID="Layer2Element"/>
<!-- A Switch a layer2 network element that when viewed
as a collection of ports has at least 1 port -->
<owl:Class rdf:ID="Switch">
<rdfs:subClassOf rdf:resource="#PortCollection"/>
<rdfs:subClassOf rdf:resource="#Layer2Element"/>
<owl:subClassOf>
<owl:Restriction>
<owl:onProprety rdf:resource="port"/>
<owl:minCardinality>1</owl:minCardinality>
</owl:Restriction>
</owl:subClassOf>
</owl:Class>
<owl:DatatypeProperty rdf:ID="speed">
<rdfs:domain rdf:resource="#Switch"/>
<rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#integer"/>
</owl:DatatypeProperty>
<owl:DatatypeProperty rdf:ID="connected">
<rdfs:domain rdf:resource="#Switch"/>
<rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#boolean"/>
</owl:DatatypeProperty>
<owl:ObjectProperty rdf:ID="port">
<rdfs:domain rdf:resource="#PortCollection"/>
<rdfs:range rdf:resource="#Port"/>
</owl:ObjectProperty>
</rdf:RDF>
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",
<http://svn.resiprocate.org/rep/ietf-drafts/rcdml/
draft-presuhn-rcdml-00.html>.
[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]