Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: EntityId decision analysis page (wasRE:[higgins-dev]entityID not an attribute?)

+1

On #1, I think more complex could get CP implementors into some
difficult situations though that's just a hunch w/o concrete examples. 
But, like Jim, I prefer simple.

On "another question", I don't see how we could guarantee immutability
or referential integrity.  I understand the need, just not how we'd pull
it off especially w/o producing a major house of cards to implement. 
Event notification from the backing store, if even possible, would still
not be guaranteed to be reliable.  Maybe doing the best we can is better
than no guarantee whatsoever.

Tom

>>> "Jim Sermersheim" <jimse@xxxxxxxxxx> 09/12/08 3:57 PM >>> 
On #2 I vote no -- it's not required to be an attribute however
there's
no requirement that restricts its value from also being reflected in
an
attribute. 

On #3, I vote 0..1 (where entities which are missing an entityID can
only be used as "blank entities".   The other use case is where one
performs a search and receives one or more Entities that are nameless.

Do people want/need that to happen? 

On #1... I dunno.  I tend to want simple. 

Another question is this:  Is the EntityID of an Entity immutable?  I
believe it must be as soon as we start tying policy to EntityIDs. 
Either that, or we need to require a way to ensure referential
integrity
for places where EntityIDs are stored in policy statements. 

Jim

>>> "Drummond Reed" <drummond.reed@xxxxxxxxxxxx> 09/12/08 1:39 PM >>>


+1 that *Contextually Unique Identifier* (CUID) accurately captures
the
requirements for the value of the Context Data Model component
currently
called *EntityID*. 


So Jim, are you suggesting that we change *EntityId*  to
*CUID*? Or just
that we just the term CUID when stating the requirements for an
EntityId
value? 


Also, please feel free to weigh in on three other questions I posed
yesterday: 


1) Must an EntityId be an identifier (string) or can it be a
collection
of attributes (multi-part key)? (Higgins 1.0, only supports the
former.)



  


2) Must an EntityId be exposed as an attribute of an Entity, or is it
optional to do that? 


  


3) Is the cardinality of EntityId 0..n or 0..1? 


=Drummond 



From: 

higgins-dev-bounces@xxxxxxxxxxx
[mailto:higgins-dev-bounces@xxxxxxxxxxx]

On Behalf Of 

Jim Sermersheim

Sent: 

Friday, September 12, 2008 1:03 AM

To: 

higgins-dev-bounces@xxxxxxxxxxx

Cc: 

'Higgins (Trust Framework) Project developer discussions'

Subject: 

Re: EntityId decision analysis page (was RE: [higgins-dev]entityIDnot
an
attribute?) 



  


Right, we talked about this on the dev call today.  EntityID should
not
be called "unique identifier" because that might imply "globally
unique".  What ppl have actually meant in the convo by "unique
identifier" is "an identifier -- unique within the context -- that
names
the entity within that context". 



  


Our original term (CUID) was much better [Contextually Unique
Identifier] 



>>> Anthony Nadalin <drsecure@xxxxxxxxxx> 09/11/08 8:32 PM >>> 

wiki is the pits

so a EntityID can't always be the unique identifier at best an
EntityID
is a reference within a context only, Lets take a cell phone, it has a
unique identity of +015128380085 but that may not tell be how I
reference this entity within a context.

Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122


"Drummond Reed" ---09/11/2008 08:24:04 PM---I took the action item on
the Higgins call today to parse the key questions being raised about
EntityId on this thread into a d 






From: 





"Drummond Reed" <drummond.reed@xxxxxxxxxxxx> 





To: 





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





Date: 





09/11/2008 08:24 PM 





Subject: 





EntityId decision analysis page (was RE: [higgins-dev] entityID not an
attribute?) 








I took the action item on the Higgi
ns call today to parse the key
questions being raised about EntityId on this thread into a decision
analysis page on the Higgins wiki. I have posted this page at: 



  



http://wiki.eclipse.org/EntityId_Requirements 



  



*and placed a link to it on 

http://wiki.eclipse.org/Context_Data_Model_1.1_Open_Issues#Open_Issues
(
http://wiki.eclipse.org/Context_Data_Model_1.1_Open_Issues#Open_Issues
)


. 



  



The ideal way to proceed is for folks to post opinions to the page and
then ping the list with a pointer. However, for those who prefer
responding in email, following is the wikitext version of the page to
which you can
 respond directly. 



  


In terms of the underlying graph model, following is a summary of the
abstract requirements derived in a recent (2008-09-11) thread on the
email list. The first step is determining if there is consensus about
these requirements. '''Please post a note with your wiki signature if
you disagree with any of the following:''' 



  



# An [[Entity]] is a node in the graph described by the Higgins
[[Context Data Model]]. The CDM needs a consistent way of representing
arcs referencing that node. 



# There MAY be 0..n such arcs referencing the node. (0 is possible for
blank nodes.) 



# An arc MAY theoretically be represented as either: 



## A unique identifier. 



## A set of [[Attribute]]s of that [[Entity]], none of which itself is
required to be a unique identifier. 



# If the arc is represented as a unique identifier: 



## It MUST be locally unique within the [[Context]], and it MAY be
globally unique across all [[Context]]s). 



  



== Higgins API Requirements == 



The second step, based on the above requirements, is answering the
following questions with respect to the Higgins API. '''Please post
your
votes/answers (with your wiki signature).''' 



  



=== #1: Unique Identifier vs. Attribute Set === 



Should the Higgins API constrain an [[EntityId]] to be a unique
identifier, or can it be a set of [[Attribute]]s? 



  



=== #2: Representation of an EntityId as a Unique Identifier === 



If an [[EntityId]] is a unique identifier, should this be represented
as: 



# A type of [[Attribute]]? 



# A separate property of an [[Entity]] that MAY be exposed as an
[[Attribute]]? 



# Inherent in the definition of an [[Entity]]? 



  



=== #3: Cardinality === 



What is the cardinality of [[EntityId]]? (The answer may depend on the
answer to #2.) 



# 0..n? 



# 0..1? 



# 1 (whose value may be null)? 



  




From: 

 higgins-dev-bounces@xxxxxxxxxxx
[mailto:higgins-dev-bounces@xxxxxxxxxxx] 
On Behalf Of 

Anthony Nadalin 

Sent: 

 Thursday, September 11, 2008 7:36 AM 

To: 

 Higgins (Trust Framework) Project developer discussions 

Cc: 

 higgins-dev; higgins-dev-bounces@xxxxxxxxxxx 

Subject: 

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



  



So there are a couple of things here, we have always talked about the
EntityID as being a reference to the Entity and not the unique
identifier. There are many ways to reference an Entity, so I don't
believe that this is limited to 0..1. I also believe that the EntityID
encapsulates a given set of attributes.The unique identifier is only
has
to be unique within a context. So I believe that the unique identifier
is an attribute, not a way to reference the Entity. 




Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122 





Paul Trevithick ---09/10/2008 05:51:39 PM---Raj has suggested the need
to clarify the language here. So here is a restatement. Additions in
red. Substitutions in blue. All 



  





From: 




Paul Trevithick <paul@xxxxxxxxxxxxxxxxx> 




To: 




higgins-dev <higgins-dev@xxxxxxxxxxx> 




Date: 




09/10/2008 05:51 PM 




Subject: 




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











Raj has suggested the need to clarify the language here. So here is a
restatement. Additions in 
red 

. Substitutions in 
blue 

. All defined terms in initial caps. 




Background: We remain committed to these two principles: 

  



· 
    

An Entity has 0..1 
unique identifier (called an 

EntityId 
) 

 (...and we expect almost all Entities will have an EntityId). 

  



· 
    

[ 
Raj 

: you asked about why this EntityId is optional. The answers are (1)
that our *complex* Attributes have values that are themselves
Entities
and we didn*t want to require developers to explicitly *name*
these
values (espec
ially in situations where there waAn Entity has 0..N Attributes some of
which may be 
used singly or in combination to identify an Entity or a set of
Entities
within a Context. 

  



· 
    

[ 
Raj 

: To date we have decided not to define an explicit *Identifier*
Attribute type. The reason for not defining it is twofold: 
First 

, the distinction between an Identifier and an Attribute has so far
proved impossible to agree on. 
Second 

, Context Provider developers are free to create their own Attribute
Definitions and thus a developer could define their own
*Identifier*
sub-Attribute] 





The proposal 
remains 

: 

  



· 
    

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 





With the above clarified and annotated definitions, I*m interested
to
hear Tony*s, Raj*s and anyone else*s reactions. 




-Paul 





On 9/9/08 1:20 PM, "Nataraj Nagaratnam" < 
natarajn@xxxxxxxxxx 

> wrote: 



Yea, there seems to be disconnect here with usage of the term
'identifier' (or Id). 

  



The statement "An Entity has 0..N Attributes some of which may be used
as identifiers" tells me that there is more than one identifier, and
then the statement "An Entity has 0..1 EntityId" says that there is
one
identifier (as i think "EntityId" means "Entity Identifier"). This
seems
to be contradicting statements in some sense, and maybe the cause of
disconnect here. 





So how about this.. 

  



· 

  

An Entity has 0..N Attributes 



· 

  

An Entity has 1 UniqueIdentifier within a given context. 





Then it makes the calculation of uniqueIdentifier to be relevant to
the
Entity within a given context; this way, we leave attributes as they
are
- if we end up using those attributes to identify/search/lookup an
entity, then fine but uniqueness is not guaranteed. Wrt those
attributes
that are used to search/lookup,.. maybe we don't need to designate
those
attributes to be identifiers in a formal manner in the data model? 




So proposal can be 



To have an IdAS getUniqueEntityId() method to return a unique
identifier
within the context of that entity, whereas other getAttribute methods
return Attributes/values 




another comment - do we really want entities without unique
identifiers
at all? 




Regards, 



Raj 








Anthony Nadalin---09/09/2008 12:40:37 PM---OK, So not sure I agree 








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/09/2008 12:40 PM 






Subject: 




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










OK, So not sure I agree 




I believe that there are 0..N EntityIDs and the EnitityID job is to
encapsulate t
he referenced attributes, thus there may be multiple
EntityIDs. 




Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122 






Paul Trevithick ---09/09/2008 10:56:26 AM---Just to make sure we*re
all
discussing the right proposal. Let me back up a bit here and restate
it:







From: 




Paul Trevithick < 
paul@xxxxxxxxxxxxxxxxx 

> 






To: 




higgins-dev < 
higgins-dev@xxxxxxxxxxx 

> 






Date: 




09/09/2008 10:56 AM 






Subject: 




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 res(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 



_______________________________________________ 


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





Back to the top