RE: [higgins-dev] entityID not an attribute?

["Tom Doman" <tdoman@xxxxxxxxxx>]

Yeah, sorry, my bad.  I actually was consciously trying to get that right
when I wrote that!  Doing the search I see I did horribly.

All the "LDAP entry ID" references are kosher, the rest should have
said "entity ID".

Tom

>>> "Drummond Reed" <drummond.reed@xxxxxxxxxxxx> 09/04/08 6:32 PM >>> 
Tom, just a quick clarification: in several places in this message you refer
to an IdAS "entry ID". Did you mean "entity ID"?

(It's an easy transposition if you live close to LDAP ;- )

> ----- Original Message-----
> From: higgins- dev- bounces@xxxxxxxxxxx [mailto:higgins- dev-
> bounces@xxxxxxxxxxx] On Behalf Of Tom Doman
> Sent: Thursday, September 04, 2008 1:46 PM
> To: higgins- dev
> Subject: Re: [higgins- dev] entityID not an attribute?
> 
> Jim and I discussed this quite a bit this AM and I believe, for the
> JNDI CP and others where the entryID isn't necessarily already an
> attribute on the entity in the backing store, that the easiest
> strategy to code to would be one in which the entityID is NOT
> considered just another attribute, as Paul proposed.
> 
> There are a number of ways in which entry IDs could be presented
> from a given LDAP entry but the "default" way would be to use some
> form of it's Distinguished Name (DN).  So far, we've just used name
> mapping rules via our Java Script Policy PDPs to make DN's look
> friendly to IdAS consumers.  For example, we return "tdoman" as
> the entity ID instead of "cn=tdoman,o=higgins,dc=com".  However,
> DN's are not searchable like attributes such as "cn" are.  So, it
> would actually be easier programatically, to separate out entityID
> searching in the JNDI CP to be a special case that has to be post
> filtered.
> 
> Now, there are other ways we could choose to map characteristics
> of an LDAP entry to an IdAS entry ID.  We could choose, via
> configuration, to use a unique attribute or a unique set of attributes
> from the entry to create it's entry ID.  For example, a GUID
> attribute.
> The simplest way to handle that case would be to return the GUID
> value as an attribute which also happened to be the value returned
> from a call to getEntryID().  Then we're not having to suppress an
> attribute as a special case in our code either.
> 
> I'm sure I'm assuming some LDAP knowledge that isn't had by all
> but I'd be happy to clarify anything that needs it but I think Jim
> gets
> where I'm coming from here and we can hash it out when he's back
> in the office.
> 
> Tom
> 
> >>> "Jim Sermersheim" <jimse@xxxxxxxxxx> 09/03/08 11:31 PM >>>
> I'd like to hear what others have to say on this topic as I know there
> are not yet many CPs that expose entityID as an attribute of an
> entity.
> 
> >>> Paul Trevithick <paul@xxxxxxxxxxxxxxxxx> 09/03/08 10:04 PM >>>
> 
> Jim,
> 
> Sounds like you think there*s good utility in keeping it the way it
> is.
> You may well be right. My reason for changing it is that doing so
> brings
> Higgins* CDM closer to RDF. It might not be a good enough reason. In
> fact, for folks that couldn*t give a hoot about RDF I realize that
> this
> is reason at all!
> 
> However, for those of us like me who already see CDM from a semantic
> (if
> not entirely from a syntactic) POV as being very close to RDF (and who
> like the power of RDF and the cool RDF tools), it makes CDM even
> easier
> to explain relative to RDF. E.g. We can say quickly that *CDM has
> the
> semantics of RDF plus a few syntactic transforms, plus Contexts, plus
> a
> more powerful identifier (UDIs vs. HTTP- URIs).*. If we keep EntityIDs
> as
> attributes (as they are in IdAS today) then we have another difference
> to explain. Namely, a kind of automatic copying of the entity*s
> intrinsic identity (its id) into an attribute of the identity. I know
> that sounded weird, but in RDF the id IS the thing, it isn*t an
> attribute of the thing. Or said another way, in RDF every id IS a node
> in the RDF graph whereas attributes (properties) are links from the
> node
> to literals or other nodes.].
> 
> Stepping back a bit, I just want to reiterate that as we all know, our
> common goal is to make IdAS a great API for java developers. To do so
> we*ve developed CDM * a set of abstractions that are at a higher
> level than RDF triples and more convenient to work with [I doubt
> there*s
> much argument about that!]. So if the consensus is that the IdAS API
> (and thus CDM) is better served by keeping this
> *auto- entityId- attribute
> management* transform the way it is in IdAS today, then heres all we
> need to do:
> 
> 
> I need to re- edit the relevant higgins wiki pages (e.g.
> http://wiki.eclipse.org/Entity, etc.) [easy]
> 
> Folks need to search and replace any code that used higgins:entityId
> to
> use cdm:entityId instead. E.g.:
> 
> Code that used
> http://www.eclipse.org/higgins/ontologies/2008/6/higgins#entityId (
> http://www.eclipse.org/higg
> ins/ontologies/2008/6/higgins#entityId )
> 
> Should now use
> http://www.eclipse.org/higgins/ontologies/2008/6/cdm.owl#entityId (
> http://www.eclipse.org/higgins/ontologies/2008/6/cdm.owl#entityId )
> 
> [why? cuz in 1.1.106 I split higgins.owl into higgins.owl and
> cdm.owl.]
> 
> 
> - Paul
> 
> 
> On 9/3/08 6:52 PM, "Jim Sermersheim" <jimse@xxxxxxxxxx> wrote:
> 
> 
> 
> 
>  I had thought we agreed that
> http://www.eclipse.org/higgins/ontologies/2008/6/higgins#entityID (
> http://www.eclipse.org/higgins/ontologies/2008/6/higgins#entityID )
> <http://www.eclipse.org/higgins/ontologies/2008/6/higgins#entityID (
> http://www.eclipse.org/higgins/ontologies/2008/6/higgins#entityID )>
> was an attribute found on every entity in a context.  In a recent mail
> from Paul, he says:
> 
> 
> 
> 
>  > My latest thinking (reflected in higgins.owl 1.1.106 and the wiki
> at
> present) is that we should NOT consider entityID to be "just another
> attribute". It should be considered something different from an
> attribute. If you want it, call getEntityID() but you won*t find it
> in
> the usual set of attributes.
> 
> 
> 
> 
> 
> 
> 
>  I'm wondering what the reason for this is.  I know that if we say
> it's
> an attribute, it allows IdAS consumers to search for entities by
> partial
> entityID in an easy way (like find me all the entities where the
> entityID begins with "tom", where if we make it a special thing, we
> need
> to have a special kind of filter element just for it.  So I just
> wanted
> to make sure the reason to not include it among attributes is worth
> losing the natural search capability.
> 
> 
> 
>  Jim
> 
> 
> 
> 
> 
> 
> _______________________________________________
> 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