Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: Strawman for 0..n entity ids [WAS: [higgins-dev] My position onEntityId]
Hmm I don't have strong opinions either.. What you say would work too.

What I thought I heard on the call (maybe I should have waited for the call notes before posting) was that an EntityId can either be
- a String as it is today, e.g. simply "jim" (which doesn't show up as an attribute)
- a value that also shows up as an attribute (typed, simple, complex, whatever)

So I thought, having the two overloaded versions of getEntity() with String and IAttributeValue would meet that very closely.

And Paul said that attributes that can be used as EntityIds must be sub-attributes of higgins:synonym, so from that follows that all IAttributeValues returned by getEntityIds() must also show up on one of the attributes of the entity.

Not sure if this meets all use cases. Maybe what you say would be better. In Java the alternative to "over-prescribing" is "making it all Objects" :)

Markus

On Fri, Sep 19, 2008 at 2:46 AM, <jimse@xxxxxxxxxx> wrote:

I like this, but I have two questions:


Why not a single IContext.getEntity(Object) (the cp can determine if it's a String, IAttributeValue, or some yet-to-be-defined thing)?  Or do we want to prevent anything other than Strings and IAttributeValues?


Why must IAttributeValues returned by IEntityId.getEntityIds() be guaranteed to also show up somewhere on the IEntity in an IAttribute that is a sub-attribute of higgins:synonym?  I mean, what's the use case(s), and what if I want to return something structured as an IAttributeValue which doesn't actually exist on the entity?  I don't have strong opinions here, I just get nervous when we over-prescribe.


Jim



>>> "Markus Sabadello" <msabadello@xxxxxxxxxxxxx> 09/18/08 11:30 AM >>>

After the call, I had this idea:

1. Let's say IEntity.getEntityIds() returns an array of Objects (in Java: Object[]). These Objects can either be Strings or IAttributeValues. If the EntityId is not exposed as an attribute, it's just a String. If it is exposed as an attribute, then it's an IAttributeValue.

2. IEntity.getCanonicalEntityId() returns a single Object. As before, if the canonical EntityId is not exposed as an attribute, then the Object is a String. Otherwise it's an IAttributeValue.

3. IContext.getEntity() has two overloaded versions. One that takes a String, and one that takes an IAttributeValue.

So in total:

public Object[] IEntityId.getEntityIds();  // Objects can either be String or IAttributeValue
public Object IEntity.getCanonicalEntityId();  // Object can either be String or IAttributeValue
public IEntity IContext.getEntity(String);
public IEntity IContext.getEntity(IAttributeValue);

You don't invent something new for typing such as key-value pairs. You simply use the existing IAttributeValue interface. IAttributeValue already includes the type. And it can be complex, so you can do multi-part keys too.

All the IAttributeValue instances returned by IEntityId.getEntityIds() are guaranteed to also show up somewhere on the IEntity in an IAttribute that is a sub-attribute of higgins:synonym.

Would that work?

Markus

On Thu, Sep 18, 2008 at 4:26 PM, Paul Trevithick

wrote:

Yesterday I created a strawman solution that we can kick around on the call today. It is described here:


And here is Tony/Mike's use case:


Shown in a diagram below a case of using N=2 identifiers: ssn and mobile telephone number:


On 9/18/08 2:31 AM, "Anthony Nadalin" <drsecure@xxxxxxxxxx> wrote:

Yes that is true, the issue is there just 1 enitityID or multiple an what is the entityID, is it an identifier, is it a reference within a context

Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122

---09/18/2008 12:41:18 AM---yeah, but are those in the same context?


From:
<jimse@xxxxxxxxxx>

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

Date:
09/18/2008 12:41 AM

Subject:
Re: [higgins-dev] My position on EntityId




yeah, but are those in the same context?


>>> Michael McIntosh <mikemci@xxxxxxxxxx> 09/17/08 12:14 PM >>>

higgins-dev-bounces@xxxxxxxxxxx wrote on 09/17/2008 10:26:05 AM:
>
> Please respond to "Higgins \(Trust Framework\) Project developer discussions"
>
> I have added my thoughts here:
> http://wiki.eclipse.org/EntityId_Requirements

>
> Here is a summary of my position (expressed in more detail on the wiki page):
> I am open to supporting the "moral equivalent" of 0..n EntityIds
> that Tony desires but I need someone to present at least one real-
> world use-case to motivate it (I've not been able to come up with one).
> By "moral equivalent" I mean:
> 0..1 "canonical" EntityId. This EntityId is unique AT LEAST within
> the scope of its containing Context. This EntityId MUST be immutable.
> 0..n synonyms. These are represented as 0..n values of a new defined
> Attribute type called something like higgins:synonym

In Entity that represents me, I can have AT LEAST the following EntityIds:
0: SSN:123-45-6789
1: IBM Employee Id: ABCDEF

_______________________________________________
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



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


Back to the top