OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dsml message

[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