[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [higgins-dev] Data Model (yet again)
|
Inline
Jim wrote:
Paul, do you imagine there being analog Java classes in IdAS to the Node
subclasses you propose below? I don't think it's a very good idea. The way
IdAS is today, we simply have typed objects (called Nodes now). The "type"
is sufficient (IMO) to represent what kind of object one has a hold of.
Agree we don't need explicit java classes for these.
I do have to agree with Raj's assertion that "Node" is too geeky, or maybe a
better word is "inaccessible". I understand the argument which goes like:
"an actual entity may be represented by a number of associated nodes", but I
also think this is easily resolvable in people's minds even if the thing
were called "Entity", "Subject", "Entry", or "Object" (terms, all of which I
prefer aesthetically to "Node").
Jim
>>> "Paul Trevithick" <paul@xxxxxxxxxxxxxxxxx> 02/22/08 1:23 AM >>>
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
<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
<http://dig.csail.mit.edu/breadcrumbs/blog/4> recognized the growing
"graph" meme. He points out that a three layer architecture is emerging:
nets
,
webs
and
graphs
. The inter
net
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
Inactive hide details for Anthony Nadalin---02/21/2008 09:38:08 PM---1. The
data mode is an un-typed mode, (no sub-classes) mak
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
Inactive hide details for
"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.
_____
size=2 width="100%" align=center>
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
