[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: LDAP and RDF data model comparison
Just following on from the notes in my data model draft... Both LDAP and RDF share the data model of a bunch of uniquely identified entries that consist of attributes, one or more of which indicate the objectclass(es) of the entry where the objectclass(es) indicate which attribute types can apply to the entry. Both also provide a means to specify constraints on attribute values. (RDF uses different terminology; entry=>resource, attributes=>property, objectclass=>type) As touched on in the data model draft notes, there are a number of differences: 1. RDF doesn't assume a tree structure (but doesn't preclude one either) 2. RDF has a notion of a DN but not an RDN (but doesn't preclude a property acting as one) 3. In RDF, property (attribute type) definitions are just resources (entries) and so are identified the same way as other resources (ie no DN versus OID distinction) 4. In RDF, a resource need not have an explicit type (ie objectclass) (however, all resources may implicitly be of type "resource"; i'll have to check as this would nullify this difference) 5. In RDF, unique identifiers are URIs, not DNs or OIDs 6. RDF allows the properties (attributes) of a resource (entry) to be specified in different places. I assume you can't do this in LDAP. So you can see that in almost every case, RDF relaxes a requirement in LDAP which still remaining a superset conceptually. If DSML is to be for "directory-like" structures and we acknowledge the similarities of LDAP and RDF as something to take advantage of, we have two options as I see it: 1. restrict the DSML data model to only be applicable to a subset of RDF that follows the restrictions of LDAP flagged in the data model footnotes 2. relax the DSML data model and allow for some operations to not be applicable where the underlying directory is LDAP. Note that 2 is the something we would probably need to handle viz different directory implementations and LDAPv3 versus LDAPv2 anyway so I don't think it would require an additional error handling mechanism. What do people think? James
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC