Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "LDAP Issues and To-Dos"

Line 2: Line 2:
  
 
#Class Definitions
 
#Class Definitions
##Handling for "ABSTRACT", "AUXILIARY", and "OBSOLETE" class definition attributes.
+
##Handling for "ABSTRACT", "AUXILIARY", and "OBSOLETE" class definitions.
 
#Attribute Definitions
 
#Attribute Definitions
##Handling for ""EQUALITY", "ORDERING", "SUBSTRING", "COLLECTIVE", "NO-USER-MODIFICATION", "USAGE", and "OBSOLETE" attributes.
+
##Handling for matching rule specification on attribute definitions.
 +
##Handling for other attribute definition terms like "COLLECTIVE", "NO-USER-MODIFICATION", "USAGE", and "OBSOLETE" attributes.
 
##Operational attribute rdfs:domain specification (part of USAGE handling).
 
##Operational attribute rdfs:domain specification (part of USAGE handling).
 
#Syntax Definitions
 
#Syntax Definitions
Line 10: Line 11:
 
##Make syntax map part of configuration file.
 
##Make syntax map part of configuration file.
 
#Matching Rules
 
#Matching Rules
##These are really only applicable during searches and will have to be dealt with behind IdAS APIs together with our query format.  Hopefully SPARQL can express what we need here, if we need anything besides the default matching rules to be applied.
+
##These are really only applicable during searches and will have to be dealt with behind IdAS APIs together with our query format.  Hopefully the IdAS Filter can express what we need here, if we need anything besides the default matching rules to be applied.
 
##I don't believe there is anything to gain in trying to represent these in OWL since they are LDAP specific and don't really apply intrinsically within OWL either.
 
##I don't believe there is anything to gain in trying to represent these in OWL since they are LDAP specific and don't really apply intrinsically within OWL either.
 
#DIT Structure, DIT Content, Nameforms
 
#DIT Structure, DIT Content, Nameforms

Revision as of 18:03, 6 October 2006

Here's the updated list of issues and todo's on our LDAP schema representation in OWL work:

  1. Class Definitions
    1. Handling for "ABSTRACT", "AUXILIARY", and "OBSOLETE" class definitions.
  2. Attribute Definitions
    1. Handling for matching rule specification on attribute definitions.
    2. Handling for other attribute definition terms like "COLLECTIVE", "NO-USER-MODIFICATION", "USAGE", and "OBSOLETE" attributes.
    3. Operational attribute rdfs:domain specification (part of USAGE handling).
  3. Syntax Definitions
    1. Expand syntax map to include other well known syntaxes and vendor specific syntaxes.
    2. Make syntax map part of configuration file.
  4. Matching Rules
    1. These are really only applicable during searches and will have to be dealt with behind IdAS APIs together with our query format. Hopefully the IdAS Filter can express what we need here, if we need anything besides the default matching rules to be applied.
    2. I don't believe there is anything to gain in trying to represent these in OWL since they are LDAP specific and don't really apply intrinsically within OWL either.
  5. DIT Structure, DIT Content, Nameforms
    1. I'm not sure what we can or should do with these yet. Any suggestions?
    2. For "version 1" of our generator, we will not attempt to support any of these in our LDAP ontologies.
  6. Schema differences between IETF Standards and rogues.
    1. See Mark's "OID and name uniqueness" e-mail and resulting thread [1]

See Also

Back to the top