[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[higgins-dev] OID and name uniqueness
- From: Mark Wahl <Mark.Wahl@xxxxxxxxxxxxxxxxxxxx>
- Date: Fri, 22 Sep 2006 11:00:02 -0500
- Delivered-to: email@example.com
- User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.13) Gecko/20060414
Comments on Tom Doman's LDAP ontology mapping:
Two issues, name and OID uniqueness, you might want to consider in your
In your mapping, it appears that if an LDAP application designer has the
same short name for an LDAP object class and for an LDAP attribute in the
directory schema, then there will be an OWL Property and an OWL Class
with the same RDF ID. (To address this, in my tool schemat I put in
prefixes "AttributeType_" and "ObjectClass_" to keep the namespace separate).
Second, while OIDs are hopefully unique within the scope of a single directory
context, as you are using urn mappings for OIDs, then there may be conflicting
definitions by different directory schemas for the same OID.
For example, comparing the definition of 126.96.36.199 (top) between
and the 6 completely different definitions of 188.8.131.52 in
If a Higgins-using developer has connections open to multiple LDAP servers,
some using the X.500/LDAP definitions of 184.108.40.206 and others based on the
Microsoft schema, then if they are all declared as
owl:equivalentClass to urn:oid:220.127.116.11, then definitions of the 'top' with
very different sets of attributes would all be equivalent.
(Similarly, OIDs for syntaxes, e.g. Microsoft has put definitions on the
joint ITU-T/ISO 2.5.5 branch, according to
and for attributes.)
To mitigate this in my schemat implementation, I chose to have OIDs be URIs that
are relative to the input source (e.g. if reading schema from an LDIF file,
they are identified by fragments e.g. file:///filename#18.104.22.168.4.1.1466...),
so that if using schema from another file, it will be necessary for there to
be an explicit import of that schema to get its OID definitions.
Informed Control Inc.