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

[Paul Trevithick <paul@xxxxxxxxxxxxxxxxx>]

Title: Re: [higgins-dev] entityID not an attribute?

Just to make sure we’re all discussing the right proposal. Let me back up a bit here and restate it:

Background: We remain committed to these two principles:

• An Entity has 0..1 EntityId  (...and we expect almost all Entities will have an EntityId)
• An Entity has 0..N Attributes some of which may be used as identifiers (that is, these attributes may singly or in combination uniquely identify an Entity within its Context)
  

The proposal is:

• To no longer consider the one, optional EntityId as an Attribute.
• To have an IdAS getEntityId() method to return this EntityId (or return null if it doesn’t exist) whereas other getAttribute methods return Attributes/values
• NOTE: CP developers remain free to present the EntityId value as the value of some Attribute type that they define and use within their Context
  

-Paul

On 9/8/08 11:29 PM, "Nataraj Nagaratnam" <natarajn@xxxxxxxxxx> wrote:

Right. A given entity can have more than one ID, but only one of them could be designated as the unique identifier.

Regards,
raj
 
 

Anthony Nadalin---09/08/2008 11:20:01 PM---I think that it does make a difference if its an attribute or not, as some entities may not have an entityID, also it matters w


From:
Anthony Nadalin/Austin/IBM@IBMUS

To:
"Higgins \(Trust Framework\) Project developer discussions" <higgins-dev@xxxxxxxxxxx>

Cc:
higgins-dev <higgins-dev@xxxxxxxxxxx>, higgins-dev-bounces@xxxxxxxxxxx

Date:
09/08/2008 11:20 PM

Subject:
Re: [higgins-dev] entityID not an attribute?

---

I think that it does make a difference if its an attribute or not, as some entities may not have an entityID, also it matters where we will look for an entityID, also I believe that entities may have multiple entityIDs

Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122

Paul Trevithick ---09/08/2008 12:37:03 PM---Thanks Tom, Jim and Markus for your input. Seems like we’re all in agreement.

From:
Paul Trevithick <paul@xxxxxxxxxxxxxxxxx>

To:
higgins-dev <higgins-dev@xxxxxxxxxxx>

Date:
09/08/2008 12:37 PM

Subject:
Re: [higgins-dev] entityID not an attribute?

---

Thanks Tom, Jim and Markus for your input. Seems like we’re all in agreement.

-Paul


On 9/5/08 11:20 AM, "Markus Sabadello" <msabadello@xxxxxxxxxxxxx <msabadello@xxxxxxxxxxxxx> > wrote:

I agree.. I think this is exactly what would feel most natural to someone new to IdAS. The entity ID identifies your entity. If it also happens to be an attribute, fine, if not, fine too.

I only wrote a single, very simple CP (for RDF data). In my case it would feel totally weird if the entity ID were itself an attribute of the entity.

Markus

On Thu, Sep 4, 2008 at 10:46 PM, Tom Doman <tdoman@xxxxxxxxxx <tdoman@xxxxxxxxxx> > wrote:

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 _javascript_ 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 <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 <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 <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/higgins/ontologies/2008/6/higgins#entityId> (
http://www.eclipse.org/higg <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> (
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 <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> )
<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 <higgins-dev@xxxxxxxxxxx>
https://dev.eclipse.org/mailman/listinfo/higgins-dev <https://dev.eclipse.org/mailman/listinfo/higgins-dev>


_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev <https://dev.eclipse.org/mailman/listinfo/higgins-dev>
_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev