Lightweight Directory Access Protocol (LDAP) has gained importance as a database technology for the storage and retrieval of information on network and human resources. This paper describes a method to create RDF models from a directory information tree or an LDAP search query by mapping LDAP schema information into OWL ontologies and LDAP objects into RDF instance triples. Furthermore, it reports on an implementation of this method based on the RDF API for PHP.
LDAP was specified by the IETF to provide an easier access to directory services
from internet clients via TCP/IP. Since 1997 LDAP v3 servers [
With respect to the Semantic Web it is important to reuse existing data
and schemata in LDAP directories within the Resource Description Framework
(RDF, [
This paper is divided into three parts. Section 1 will describe the method to
generate an OWL ontology from a LDAP schema. On the basis of this, section
1 For a more complete introduction to LDAP see [
The schema specification of an LDAP server consists of four parts: the definition of object classes and attribute types, and an index of attibute syntaxes and matching rules implemented on the server. Every class, type, syntax and rule is globally identified by an object identifier (OID2) and locally by one or more mnemonic names.
An requirement for the whole process is a small vocabulary which describes base entities of the LDAP world: object is the class of all LDAP objects and hasDITChild / hasDITParent is a pair of (inverse) functional object relations who represent the DIT structure. For a one-way conversion of existing LDAP data into RDF data, only this basic vocabulary is necessary. A more complete LDAP schema ontology will be presented in [7]3.
The next three subsections explain the rules of how to convert a LDAP schema with types and classes to an OWL ontology. 1.1
Attribute syntax Because the different attribute syntaxes (e.g. the telephone number syntax or the integer syntax) are only named in the schema but not declared, dealing with them can only be achieved by a mapping table in which each syntax OID is put together with the URI of its matching XML Schema datatype. Most of them can simply be matched with xsd:string4, but in some cases we can map to more specific datatypes or we must bear in mind other constraints. These exceptions are: – The DN and OID syntax must be ignored, because attributes of this type are transformed into object properties. – The values of any binary syntax attributes should be recoded as the XML
Schema datatype xsd:base64Binary.
– The Directory String syntax should be xsd:normalizedString because no
new lines are allowed here.
– Numeric syntaxes must be mapped to an equivalent numeric XML Schema
datatype, if possible.
2 OID are strings of dot-separated numbers which form a hierarchical structure. They
were first specified in the ITU-T recommendation X.208 (ASN.1) and are used to
identify objects in the broadest sense. An OID can be transformed into an URN by
using the prefix urn:oid: [
Each attribute schema definition will be transformed into OWL according to the following implementation rules: – Every attribute with the syntax of an OID or a DN is created as an object property while all others become datatype properties6. – If there is a super-attribute, the RDFS relation rdfs:subPropertyOf should be used. – Object properties get as range the class top7 and datatype properties the matching XML Schema syntax. – Local names are used as part of the URI of the new property. The first URI is described explicitly, any other URI and the OID (in URN form) are mapped with owl:equivalentProperty to the first one. – The local name should also be used as the value of a rdfs:label property. 5 Assumimg the OID prefix wm is set to 1.3.6.1.4.1.1466.115.121.1 . 6 In general, the OID syntax is only used in administrative attributes. 7 According to RFC 2251, the root of any schema class hierarchy has to be top. – If there is a single value indicator in the schema definition, then a cardinality restriction (≤ 1) for the class top must be created on this property8. – The domain of the property will be generated with the owl:unionOf class constructor and the list of all object classes which use this attribute (no need for owl:unionOf if there is only one domain class).
An example for a transformed LDAP attribute is presented with the next lines of RDF/XML code. In the sample schema, the single value attribute countryName is only used in the object class country, therefore its domain is given by country. The schema definition of an object class can contain two different reference types to an attribute. It depends on this type whether an attribute is mandatory in all objects of this class (MUST) or whether it is allowed and optional (MAY). Furthermore, the definition consists of a local name, an OID and an optional description. All classes are arranged in a subclass hierarchy whose root is the class top. Subclasses inherit all attribute conditions of its superclasses9. To generate OWL classes from LDAP schema classes, these implementation rules must be followed: – The local name must be used as part of the URI of the new OWL class.
Additionally, the OID (in URN form) is mapped with owl:equivalentClass to the class. It is theoretically possible to create an ontology only by using URN-formed OIDs but in fact, many tools do not support URNs so it is more workable to generate a new URL for each class (and property). 8 Using top instead of the domain classes is necessary because the single value restriction is set for the whole LDAP schema and not for the particular domain classes. 9 In an LDAP schema more than one direct superclass is possible. – The local name should also be used as the value of a rdfs:label property. – For every mandatory attribute of the object class a new cardinality restriction (= 1) has to be created on the OWL class. – The new class has to be in rdfs:subClassOf-relation with its superclass(es) (in most cases just top). top must be defined as a subclass of the generic LDAP object class ldap:object from [9].
As an example, the next XML listing shows the converted standard object class country which has the mandatory attribute countryName. 1 <owl : Class rdf : about ="# country "> 2 < rdfs : label > country </ rdfs : label > 3 < rdfs : subClassOf rdf : resource ="& ldap ; top " /> 4 <owl : equivalentClass rdf : resource =" urn : oid :2.5.6.2"/ > 5 < rdfs : comment > RFC2256 : a country </ rdfs : comment > 6 < rdfs : subClassOf > 7 <owl : Restriction > 8 <owl : cardinality >1 </ owl : cardinality > 9 <owl : onProperty rdf : resource ="# c" /> 10 </ owl : Restriction > 11 </ rdfs : subClassOf > 12 </ owl : Class >
The resulting OWL schema requires at least OWL DL because of the owl:unionOf class constructor. 2
To convert the directory objects from a DIT into an RDF model, the classes and properties of the previously created OWL ontology and the basic LDAP ontology have to be used. While doing this, these steps have to be followed: – Construct the URI of the LDAP object according to RFC 1959 [10]. This means that the object gets an URI in the form ldap://[host]/[URL encoded DN], e.g. ldap://ldap.example.org/c=de. – Identify the main structural object class in order to take this as the rdf:type of the object. Any auxiliary classes become additional types. – Convert all attribute values from DN and OID syntax attributes into resources and create that object property triple. – Convert all other attribute values to literals10 and create a datatype property triple. – Use the objects RDN value as a rdfs:label.
As a result of this process, a typical LDAP object of the organization type gets an RDF representation which looks like this: 10 Binary values have to be encoded as xsd:base64Binary. 1 < organization rdf : about =" ldap :// example . org /o= IMISE ,c= de "> 2 < rdf : type rdf : resource ="# labeledURIObject " /> 3 < rdfs : label > IMISE </ rdfs : label > 4 <o > IMISE </o > 5 < telephoneNumber >+49 341 97 16100 </ telephoneNumber > 6 < labeledURI > http :// www . imise . de / </ labeledURI > 7 < description > Institute for ... </ description > 8 < ldap : hasParent rdf : resource =" ldap :// example . org /c= de "/ > 9 </ organization >
With this method it is possible to convert a complete LDAP directory including schema and data. At the same time only parts of a DIT, e.g. a result set of an LDAP query can be converted into and reused in RDF. In the next section, I will briefly explain an PHP implementation that is based on the PHP API RAP.
As a proof of the concept, I have implemented the method in the server-side script language PHP as a web application using the wrapper functions to the OpenLDAP library and classes for the schema and server handling from the open-source project phpLDAPadmin on the LDAP side as well as the PHP API RAP on the RDF side.
Implementation was rather simple because all the used libraries are mature and well-documented projects. For the test run, I converted the IMISE LDAP Server with over 300 schema items and 2300 DIT objects into RDF. The current version of the ldap2owl.php script is free accessable11. 11 http://purl.org/net/ldap/ldap2owl.php 7. Dietzold, S.: LDAP and the Semantic Web. in preparation (2005) 8. Schulzrinne, H.: The tel URI for Telephone Numbers. RFC 3966, The Internet
Engineering Task Force (IETF) (2004) http://www.ietf.org/rfc/rfc3966.txt. 9. Dietzold, S.: Basic vocabulary to use LDAP data in RDF. OWL ontology (2005) http://purl.org/net/ldap. 10. Howes, T.A., Smith, M.C.: An LDAP URL Format. RFC 1959, The Internet Engineering Task Force (IETF) (1996) http://www.ietf.org/rfc/rfc1959.txt.