Hi Jim and other Higgins'ers
A thought/suggestion:
In IDigitalSubject you have a method:
String getUniqueID()
I would suggest that you consider generalizing this to allow multiple
types of ID (i.e. other than String), by having a new ID interface
ID getUniqueID()
In ECF we do this and ID is an interface that extends
java.security.Principal (and therefore has a String getName()) method,
and extends IAdaptable, so that adapters for IDs can exist.
In ECF, we use a plugin org.eclipse.ecf.identity that declares ID (see
identity package javadoc here:
http://www.eclipse.org/ecf/org.eclipse.ecf.docs/api/org/eclipse/ecf/core/identity/package-frame.html).
The semantics of IDs are assumed to be simply a unique ID (usable for
uniquely identifying users, processes, roles, services, digital
subjects, etc., etc). Obviously since it extends Principal it also
serves as a principal within JAAS.
We've found that having ID be defined as an interface and providing an
extension point to allow people to define custom types of ID (rather
than referring directly to a String) has been of use for ECF, and it
could also be of value for Higgins. So it might be of use to think
about having Higgins IDs potentially have more general structure than
String.
Just a thought of potential reuse across projects (some notion of an
abstract unique identifier...aka ID).
Scott
Jim Sermersheim wrote:
IDigitalSubject now is just like it used to be in the sense that
it doesn't derive from any interfaces meant to be used on their own (it
does extend IHasRelationships, IHasMetadata, and IHasAttributes). It
again is the only thing that has a "name" (and that has been reset back
to uniqueIdentifier as it was originally).
There is an interface caled IPropertyValue (this is actually a
week or so old). It has two sub-interfaces: ISimpleValue, and
IComplexValue. IComplexValue has attributes so it also extends
IHasAttributes.
As far as basic impl's go, there is a BasicSimpleValue,
BasicComplexValue, and one extension of BasicSimpleValue for each
simple XML datatype used in OWL.
(re)starting from there, what should we do to clarify/improve
things?
I still do not understand the introduction of IResource either
(assuming IEntity is planning to be removed)
Original intent was that
- There are entities in real world (not modeled). Examples are
users, organizations, devices, systems, etc
- An entity can have multiple identities, such that a given
identity is scoped to a context
- It is the digital representation of that identity that we would
be working with
- Original plan was to call that DigitalIdentity - both the
attribute representation (that is stored/managed), as well as the
representation during an interaction with a relying party. Then we
decided to stick with DI to represent claims.. and thus its role in the
interaction aspects; and DigitalSubject to represent the digital
representation of an entity in the context of its attributes
- Types of entities would be represented as typed DigitalSubjects
- I was assuming we will have UserSubject, DeviceSubject, etc.
>From that notes and proposed changes, it looks like we are
introducing IResource; are we then treating DigitalSubject to only
represent user types? Why? If we really want to use the term Subject to
represent user types, then I would rather introduce DigitalIdentity as
the super type (to represent the reflection of attributes; as well as
claims), than introduce a Resource as the higher level abstraction.
Thanks
Raj
![Inactive hide details for Greg Byrd <gbyrd@xxxxxxxx>]() Greg Byrd <gbyrd@xxxxxxxx>
It's just a suggestion. I'll be happy to hear input from others.
If, however, IResource is meant to encapsulate a resource in the RDF
sense, then it makes sense to me that IDigitalSubject is a specific
type
of resource. In other words, a DS will always be a resource in the RDF
sense. So if we're exposing the notion of RDF resource through the
API,
then it's consistent to view IDigitalSubject that way.
Just to play Devil's advocate -- if we're exposing RDF notions in the
API, why not use Jena or some other API instead of inventing our own.
They already have Resource, Literal, etc. (The practical answer might
be that it takes too long to get permission from Eclipse to include
third-party code...)
...Greg
Jim Sermersheim wrote:
> We can do it that way. I was hesitant to do that because I didn't
know
> where IResource might differ from IDigitalSubject in the future.
>
> I'll change it to follow your suggestion, and we can deal with
> divergence of IResource if/when that ever happens.
>
> Jim
>
> >>> Greg Byrd <gbyrd@xxxxxxxx> 9/20/06 7:11 AM
>>>
>
> So how about making IDigitalSubject a sub-interface of IResource?
I
> don't see the need for another interface type that has no other
uses,
> and IResource doesn't add anything to IEntity anyway, except for
also
> implementing IHasMetadata.
>
> ...Greg
>
>
> Jim Sermersheim wrote:
> > Oops, we were talking about it on the #higgins chat channel,
and I
> > forgot it wasn't discussed here.
> >
> > Well, not much of a debate. I added IResource and ILiteral
interfaces
> > sometime back (for attribute value types). Today I finally
got around
> > to fleshing out IResource and noticed for the second time
that it's
> > almost exactly like IDigitalSubject (just doesn't have a
Context). So
> > rather that duplicating the APIs having to do with
attributes, name,
> > and type, I proposed a super-interface for tha t.
> >
> > We debated between IObject and IEntity. I'm open to other
names or
> > solutions if they're better.
> >
> > Jim
> >
> > >>> Greg Byrd <gbyrd@xxxxxxxx> 9/19/06 6:32 PM
>>>
> >
> > So I missed this debate -- what's the reason for the change
to IEntity?
> >
> > ...Greg
> >
> >
> > Jim Sermersheim wrote:
> > > For all you context provider writers out there, I forgot
to tell you
> > > that as part of the creation of the more generic
IEntity, the method
> > > name changed (was IDigitalSubject.getUniqueID, is now
> > > IEntity.getName). In terms of its use on
IDigitalSubject, it's still
> > > the Contextually Unique Identifier. I suppose that's
true for its use
> > > on IResource as well. Hmm, maybe I should have left the
name
> > > alone... Opinions?
> > >
> > > Jim
> > >
> >
> > _ ______________________________________________
> > higgins-dev mailing list
> > higgins-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/higgins-dev
> >
------------------------------------------------------------------------
> >
> > _______________________________________________
> > higgins-dev mailing list
> > higgins-dev@eclipseorg
> > 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
>
_______________________________________________
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
|
