Re: [higgins-dev] OID and name uniqueness

["Tom Doman" <TDoman@xxxxxxxxxx>]

Oh, sorry Mark, on issue 1, did you mean that sometimes attributes and object classes have the same name?  I thought you getting at something else.  Yeah, I need to handle that.  I could get fancy or just blindly prefix them all.

Tom Doman
Novell Inc.

>>> "Tom Doman" <TDoman@xxxxxxxxxx> 9/22/2006 10:40 AM >>>
Thanks Mark!  A couple of questions:

1. On issue 1, aren't the namespaces separate already because my mappings are all, in my example, technically "&bandit;<class or attribute name>"?  Or is it more just to avoid potential confusion?  I like the idea either way and will incorporate it into my JNDI context provider implementation, I just want to understand the potential pitfall better.

2. On issue 2, would you suggest then that I prefix the schema with the server address the schema was mapped from to help mitigate the issue you raise?  e.g. ldap://servername:port#1.3.6.1.4.1.1466...  I'd hate to do that for every server especially when most of the "multiple LDAP servers" share the exact same schema.  I guess we could do some inspection against known or our "preferred" definitions and only tag the ones that differ from that.

3. I've been doing a little reading on your tool schemat on ldap.com and see that the source code is available there.  Do you have an output sample you'd be willing to post or send?  I still have several issues I'm unsure OWL will support from LDAP.  I listed them in my "Latest OWL Ontology from LDAP Schema" e-mail and I'd love to collaborate on them with anyone that's interested in contributing to Higgins.

Tom Doman
Novell Inc.

>>> Mark Wahl <Mark.Wahl@xxxxxxxxxxxxxxxxxxxx> 9/22/2006 10:00 AM >>>
Comments on Tom Doman's LDAP ontology mapping:



Two issues, name and OID uniqueness, you might want to consider in your
schema mapping.

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 2.5.6.0 (top) between
http://www.itu.int/ITU-T/asn1/database/itu-t/x/x501/2005/InformationFramework.asn 
and the 6 completely different definitions of 2.5.6.0 in
http://windowssdk.msdn.microsoft.com/en-us/library/ms683975.aspx 

If a Higgins-using developer has connections open to multiple LDAP servers,
some using the X.500/LDAP definitions of 2.5.6.0 and others based on the
Microsoft schema, then if they are all declared as
owl:equivalentClass to urn:oid:2.5.6.0, 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
http://technet2.microsoft.com/WindowsServer/en/library/97cae647-d996-48ff-b478-c96193abeadb1033.mspx?mfr=true 
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#1.3.6.1.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.


Mark Wahl
Informed Control 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