[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [higgins-dev] Issues: LDAP schema representation in OWL
|
I took the liberty of posting this content here
http://wiki.eclipse.org/index.php/LDAP_Issues_and_To-Dos which you can now
get to from http://wiki.eclipse.org/index.php/IdAS_Data_Model
> -----Original Message-----
> From: higgins-dev-bounces@xxxxxxxxxxx [mailto:higgins-dev-
> bounces@xxxxxxxxxxx] On Behalf Of Tom Doman
> Sent: Tuesday, October 03, 2006 6:48 PM
> To: higgins-dev@xxxxxxxxxxx; Mark.Wahl@xxxxxxxxxxxxxxxxxxxx
> Subject: 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
> _______________________________________________
> higgins-dev mailing list
> higgins-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/higgins-dev
