Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [higgins-dev] Issues: LDAP schema representation in OWL

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

1. Class Definitions
	a. Handling for "ABSTRACT", "AUXILIARY", and "OBSOLETE" class definition attributes.

2. Attribute Definitions
	a. Handling for ""EQUALITY", "ORDERING", "SUBSTRING", "SINGLE-VALUE", "COLLECTIVE", "NO-USER-MODIFICATION", "USAGE", and "OBSOLETE" attributes.
	b. Operational attribute rdfs:domain specification (part of USAGE handling).

3. Syntax Definitions
	a. Expand syntax map to include other well known syntaxes and vendor specific syntaxes.
	b. Make syntax map part of configuration file.

4. Matching Rules
	a. 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.
	b. 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
	a. I'm not sure what we can or should do with these yet.  Any suggestions?
	b. 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.
	a. See Mark's "OID and name uniqueness" e-mail and resulting thread.

Tom Doman
Novell Inc.

>>> "Tom Doman" <TDoman@xxxxxxxxxx> 9/26/2006 5:15 PM >>>
For those who are interested, here's the current list of issues to resolve on our LDAP schema representation in OWL work:

1. Class Definitions
	a. Handling for "ABSTRACT", "AUXILIARY", and "OBSOLETE" attributes.
	b. Handling attribute name collisions.

2. Attribute Definitions
	a. Handling for ""EQUALITY", "ORDERING", "SUBSTRING", "SINGLE-VALUE", "COLLECTIVE", "NO-USER-MODIFICATION", "USAGE", and "OBSOLETE" attributes.
	b. Operational attribute rdfs:domain specification (part of USAGE handling).
	c. Handling class name collisions.
	d. Syntax mapping for rdfs:range element.  Currently, everything is a StringDatatype attribute unless it's an octet string which I set Base64BinaryDatatype.

3. Syntax Definitions
	a. Define Higgins based ObjectProperties for LDAP syntaxes that can be used in the mapping stage in 2.d.

4. Matching Rules
	a. 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.
	b. 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 withing OWL either.

5. DIT Structure, DIT Content, Nameforms
	a. I'm not sure what we can or should do with these yet.  Any suggestions?
	b. For now, we'll not try to reflect these in our LDAP ontologies.

6. Schema differences between IETF Standards and rogues.
	a. See Mark's "OID and name uniqueness" e-mail and resulting thread.

Tom Doman
Novell Inc.

_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx 
https://dev.eclipse.org/mailman/listinfo/higgins-dev


Back to the top