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 Node; a contextualized aspect of a natural
person)
o
Group (a subclass of Node; a class of Agents (can be used as a
role))
o
Organization (a subclass of Node; 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>
|
|
|
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)
|
|
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
