[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [higgins-dev] Data Model (yet again)
|
Another "core" subclass to
consider is Account (or something that represents the attributes needed
to authenticate to a system). It is important to figure this out
early in the subclassing, because many repositories represent accounts
as additional attributes of a Person and other repositories represent the
account as separate from the Person. In addition not all accounts are Persons,
the account could represent a device, application, or a group.
Thanks,
David
Nataraj Nagaratnam/Raleigh/IBM@IBMUS
Sent by: higgins-dev-bounces@xxxxxxxxxxx
02/22/2008 10:44 AM
|
Please respond to
"Higgins \(Trust Framework\) Project developer discussions"
<higgins-dev@xxxxxxxxxxx> |
|
|
To
| "Higgins \(Trust Framework\) Project
developer discussions" <higgins-dev@xxxxxxxxxxx>
|
|
cc
| "'Higgins \(Trust Framework\) Project
developer discussions'" <higgins-dev@xxxxxxxxxxx>, higgins-dev-bounces@xxxxxxxxxxx
|
|
Subject
| RE: [higgins-dev] Data Model (yet again) |
|
[BTW Raj, Unless you’ve
changed, I know you’re roughly in support of adding these 4 new, low level,
classes into the Higgins data model, because I remember they were present
in your UML data model proposals from years ago!]
On the specialization/subclass of Node (or Entity ;-))
Yes, conceptually am in support of such specialization. When we proposed
this years ago (man .. its been a while!), we agreed to start with core
model and to revisit the specialization. Now is a good time to get into
specialization and thats good to see.
Person, Group and Org are easier ones to start and deal with - as those
are quite well understood. One other type that we discussed that time was
Role - I do realize a Role has so many interpretations, and ways to achieve
- as a type of Node/Agent, attribute to a Node/Agent, etc. We can revisit
this at a later time once we get better with dealing with Person/Group/Org.
What needs to be done next is to look at the level of APIs, and class structure.
This goes to Tony's point about the need to make the APIs/model friendly
to tooling environment as well.
thanks
Raj
"Paul
Trevithick" ---02/22/2008 09:00:43 AM---Correction in red inline.
"Paul Trevithick" <paul@xxxxxxxxxxxxxxxxx>
Sent by: higgins-dev-bounces@xxxxxxxxxxx
02/22/2008 08:26 AM
|
Please respond to
"Higgins \(Trust Framework\) Project developer discussions" <higgins-dev@xxxxxxxxxxx> |
|
|
Correction in red
inline.
From: higgins-dev-bounces@xxxxxxxxxxx
[mailto:higgins-dev-bounces@xxxxxxxxxxx]
On Behalf Of Paul Trevithick
Sent: Friday, February 22, 2008 1:23 AM
To: 'Higgins (Trust Framework) Project developer discussions'
Cc: higgins-dev-bounces@xxxxxxxxxxx
Subject: RE: [higgins-dev] Data Model (yet again)
Hi Raj,
The word node is the result of lots of discussions. I’m personally of
the opinion that the most innovative thing about the Higgins data model
is the node relation—that is, the ability to relate and correlate
multiple nodes into an “overlay” graph that spans both legacy
and green field (e.g. RDF) data stores/silos (and each using a different
wire protocol!). I think node reinforces this.
I feel it is very important for Higgins to be more relevant to the social
network, Web 2.0 and http://dataportability.org
folks. This crowd is very comfortable talking about the social graph, links,
and nodes. I keep hearing about Web 2.0 folks who don’t understand what
Higgins is and are trying to reinvent it. We’re already, by the makeup
of the Higgins development community relevant to the enterprise/directory
crowd---it’s these new kids on the block that we need to be relevant to.
Even TimBL has, for example, in this
blog post recognized
the growing “graph” meme. He points out that a three layer architecture
is emerging: nets, webs and graphs. The internet
moves packets around. The world wide web interconnects a planet
full of documents. And what he calls the “Giant Global Graph” is what
he hopes the semantic web will be. And what I think the Higgins Global
Graph will be.
Another thing that I feel is so important, yet subtle, is the way that
the Higgins data model emphasizes the multi-contextual nature of identity.
One physical entity (e.g. a person) is represented by many nodes, not one.
Each node is a machine representation of ONE partial, aspect of the physical
person. Only by linking together with what we call node correlation
links can a more complete, composite (though not necessarily self-consistent).
So one person is represented by multiple nodes in multiple contexts.
But having said all of this. Now that 1.0 is out of the way, spurred by
the need to represent access control policy (including role-based access
control), we have reached the point where we need to add new terms/concepts
that specialize node. We will be having a one hour telecon to discuss my
proposed additions in the coming week (I must remember to send out an email
tomorrow about this), but I hope you’ll be happy to learn that these four
subclasses of node are being proposed:
ยท
Agent (a subclass of
Node; a person, organization, or computing system)
o
Person (a subclass of
Agent;
a contextualized aspect of a natural person)
o Group
(a subclass of Agent;
a class of Agents (can be used as a role))
o Organization
(a subclass of Agent;
an organization, department, etc.)
My point is this. In practice, 99% of all nodes will be persons,
groups or organizations. So you won’t have to wince at the
geeky “node” word too much.
-Paul
[BTW Raj, Unless you’ve changed, I know you’re roughly in support
of adding these 4 new, low level, classes into the Higgins data model,
because I remember they were present in your UML data model proposals from
years ago!]
From: higgins-dev-bounces@xxxxxxxxxxx
[mailto:higgins-dev-bounces@xxxxxxxxxxx]
On Behalf Of Nataraj Nagaratnam
Sent: Thursday, February 21, 2008 11:48 PM
To: Higgins (Trust Framework) Project developer discussions
Cc: Higgins (Trust Framework) Project developer discussions; higgins-dev-bounces@xxxxxxxxxxx
Subject: RE: [higgins-dev] Data Model (yet again)
Another point - though we had discussed
the point in the past, increasingly when I present Higgins Data Model to
developers and customers - they give me a look when they look at the term
"Node" ;-(
Any chance we can revisit this again please? The term Node is too geeky,
graph oriented. So a name that people can kind of understand would be a
better choice - I haven't had any problems talking about 'entity' and audience
get it and fits well with context, relationship, etc.
comments?
thanks
Raj
Anthony
Nadalin---02/21/2008 09:38:08 PM---1. The data mode is an un-typed mode,
(no sub-classes) makes you look at each instance to determine its type,
this is not suita
Anthony Nadalin/Austin/IBM@IBMUS
Sent by: higgins-dev-bounces@xxxxxxxxxxx
02/21/2008 09:34 PM
|
Please respond to
"Higgins \(Trust Framework\) Project developer discussions" <higgins-dev@xxxxxxxxxxx> |
|
|
1. The data mode is an un-typed mode, (no sub-classes) makes you look at
each instance to determine its type, this is not suitable for data mining
and creating graphs of the data charateristic.
3. Yes
Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122
"Paul
Trevithick" ---02/21/2008 04:26:08 PM---1. I don’t understand.
From:
| 
"Paul Trevithick" <paul@xxxxxxxxxxxxxxxxx>
|
To:
| 
"'Higgins \(Trust Framework\) Project developer discussions'"
<higgins-dev@xxxxxxxxxxx>
|
Date:
| 
02/21/2008 04:26 PM
|
Subject:
| 
RE: [higgins-dev] Data Model (yet again) |
1. I don’t understand.
2. I was informed today on the call that I missed some emails on the higgins-dev
list in the past week on that topic. From what folks on the call said:
(a) they agree with you (b) apparently there is some rough consensus on
what to do about it. I’ll learn more as I re-read the higgins-dev list.
3. Hmm. Let me see if I understand your issue…. Given Node (N1) that has
two Node Relations emanating from it, e.g one pointing to N2 and another
pointing to N3, then are you saying that we’re lacking a way to “tag”
or otherwise distinguish between these two Node Relations?
BTW, here are some other things that the data model is missing off the
top of my head…
1. Access control policy _expression_: We agreed on the call today that we’ll
schedule a dedicated call about this in the next week. I’ll send links
to a proposal for a very rudimentary access control approach along with
the meeting invites.
2. As discussed at the F2F in Provo: the ability for the model to express
policy information at the IdAS/CP/data-model level that today can only
be expressed by an STS. The use case that we want to support is a “recursive”
case where someone layers IdAS over, say, an LDAP data store on the one
hand (that’s easy), and context provider that is “fronting” an STS on
the other hand. The problem is that the IdAS consumer can’t query for
the STS’s policy.
3. Other things… (e.g. how to declare Node classes as “closed”)…etc.
From: higgins-dev-bounces@xxxxxxxxxxx
[mailto:higgins-dev-bounces@xxxxxxxxxxx]
On Behalf Of Anthony Nadalin
Sent: Thursday, February 21, 2008 4:54 PM
To: 'Higgins (Trust Framework) Project developer discussions'
Subject: [higgins-dev] Data Model (yet again)
So I don't feel like we are quite
there yet for several reasons:
1. This is a runtime data model, there are not yet any tools that can create
the graphs that I think folks might need
2. There still is no direct way for one node to reference a specific attribute
or specific type of attribute in a different context/node
3. When using relations there is now way to tell what relation we are really
talking about
Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122_______________________________________________
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
