Thank you, Dustin, that's perfect! It's more than a decade since I did any work with LDAP, so I'm very rusty. Before getting down to work to refresh my knowledge, I just wanted to be sure I was barking up the right tree - I may well be back with more questions in the next few weeks...
On 21 April 2010 19:29, Dustin Puryear <[email protected]> wrote: > To answer one of your questions: I believe you go through IANA to get a > OID, although it's been so long since I've done that so I may be wrong. > > > > One quick note: Be sure to name the attributes with an org identifier, > e.g., you would name responsible as yourOrgResponsible. This reduces the > chance that you will use a custom attribute name that somebody else uses but > for different purposes. > > > > As far as " Obviously there'd be much more to it than this, but the > authorised person ought to be able to update the status whilst others can > read it, with the status being, effectively, an enum or enumerated type.", > yes, with LDAP you can do all of that. > > > > I'm happy to help further. > > > > Thanks. > > > > *From:* Peter Brooks [mailto:[email protected]] > *Sent:* Wednesday, April 21, 2010 11:36 AM > *To:* Dustin Puryear > *Cc:* [email protected] > *Subject:* Re: [ldap] Using ldap to support an ontology > > > > On 21 April 2010 17:46, Dustin Puryear <[email protected]> wrote: > > Can you be a little more specific in what you're trying to do? What kind > of data are you going to store? Do you need to do any serious > computations based on that data? > > > > Yes, I do. The data are the triplets of an ontology. I'm looking at it as > a means of keeping, and updating, status and other details of strings of > records of an ontology. Here's some pseudo code that I hope gives a flavour: > > > > attributetype ( > > 1.3.6.1.4.1.4203.666.42.40 > > NAME 'responsible' > > SYNTAX '1.3.6.1.4.1.1466.115.121.1.12' > > SINGLE-VALUE ) > > attributetype ( > > NAME 'status' > > SYNTAX '1.3.6.1.4.1.1466.115.121.1.15' ) > > objectclass ( > > 1.3.6.1.4.1.4203.666.42.50 > > NAME 'service-status' > > SUP leaf > > ABSTRACT > > MAY (status $ responsible) ) > > objectclass ( > > 1.3.6.1.4.1.4203.666.42.70 > > NAME 'SDP' > > SUP top > > AUXILIARY > > DESC 'Service Design Package' > > MAY ( service-status $ service-name $ > > service-owner $ > > SDP-Version ) ) > > > > Obviously there'd be much more to it than this, but the authorised person > ought to be able to update the status whilst others can read it, with the > status being, effectively, an enum or enumerated type. > > > > Does this make it any clearer? > > > > >
