To go along with this, today I've mostly been trying to
map/reconcile between the terminology on http://spwiki.editme.com/Higgins and
the interfaces/classes in the API. Here are my guesses (wiki term -> API
element):
- Claim -> An implementation of IProperty (except the
name is missing). Maybe an instance of an IProperty and IPropertyName held in
an IPropertyContainer. Not quite…
- Claim
-> (not yet implemented. We currently have only raw Identity Attributes that
are missing “claimants”)
- Identity
Attribute -> IProperty (IProperties have IPropertyNames). A DigitalIdentity
is an IPropertyContainer.
- Context Service/Provider
-> an instance of an implementation of IContext
- Digital Identity -> an instance of an implementation
of IMember
- Digital Subject -> none
- Link -> an instance of an implementation of IEdge
Are any of those right? Most. See above.
As an aside, what does the "E" refer to when seen
in sub-interfaces (like IEContext, IEProperty, ...). Not sure if it refers to
ecore, some other aspect of EMF or something else altogether.
The extra “E”
is related to EMF. In EMF you create an interface definition that EMF uses to auto-generates
a class. So IEContext is the EMF interface used to auto-generate IEContextImpl.
IContext is the pure Higgins interface that should be used in/with the Higgins API.
The general pattern is that IEContextImpl implements IContext. By using the
pure IContext interface, all implementation details (e.g. using EMF or not) are
hidden.
>>> Dale Olds <dolds@xxxxxxxxxx> 3/9/06 2:37:44 pm >>>
I would like to discuss some terms in the context of Higgins interfaces and
classes. At this point I would rather not revisit any of these terms in the
sense of the identitygang lexicon, but see if we can reach a common
understanding in a more narrow scope of Higgins interfaces and code.
Entity
====
I know that "entity" is not in the interfaces or classes and is not
modeled directly, but I find it useful (and even necessary) to describe things
in the real world and we should be clear about what we consider to be "real"
and "things". I think "entity" is the most likely term.
Claims, attributes, digital identities, digital subject, and principals all
purport to be data about something -- some entity. I think of an
"entity" as anything that can be identified in human conversation.
This is very close to the identity gang lexicon, except that it would include
"concept" i n the list with person, physical object, animal, and
juridical entity. In fact, I think of a juridical entity as a conceptual entity
that incurs legal policy. Also, note that a false assertion is still a concept
-- we can identify it and talk about it.
So it is useful to think of an entity as anything that can be identified in
human conversation. There is much discussion on the identitygang list that two identities
can be identical -- but I think that's because the discussion strays between
entities (anything that can be identified) and digital identities (a chunk of
data). Of course a particular chunk of data (e.g. a set of attributes) can be
insufficient to distinguish between two entities, but humans CAN distinguish
between the entities or we could not talk about them. The distinction between
entities may be as simple as sequence or physical position, be we can identify
them or we could not discuss them.
Digital Identity
===========
In networke d systems we commonly store data about an entity. I think this
corresponds most closely with Digital Identity. It consists of a chunk of
structured data. At this point I see no difference between the terms attributes,
attribute value assertions, and claims when applied to that structured data.
Sometimes sets of attributes are stored as an entity within a larger entity
(e.g a user account within a directory service). Sometimes a set of attributes
are presented as part of some interaction with another entity (e.g.
name.password authentication, update address book, present credit card info,
etc.). Is this the difference between "digital subject",
"digital identity", and "claims" -- merely notions of
persistence and larger or smaller subset of attributes? If so, it seems like
the higgins interface can have class definitions for digital identity, and
attribute, and not (yet) need classes for digital subject, claims, persona,
party, etc.
>From what I have seen of the de mo code, it seems like a Facet corresponds
to a digital identity. Is this where you see it going?
--Dale
