[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [higgins-dev] Data Model (yet again)
|
I agree. I don't often weigh in on this kind of discussion, but I feel
rather strongly about this one. Node is a term that is too easily
confused with so much else that developers have to deal with. It comes
with too many other connotations and baggage that has to be sifted
through. I think we did ourselves a disservice in choosing that term.
It only leads to confusion and possibly ridicule once they realize what
it is - if they stick around long enough to "get it."
I think the terms "entity" or even "object" are much more familiar and
easy to explain. In fact, I would argue that they need no explaining at
all in most circles of developers. They are well understood by anyone
who does any data modeling at all and they do not preclude any of the
"relationship" concepts that are so important in Higgins. In fact, they
embrace it rather well - ER diagrams come to mind. It is also well
understood that "entities" or "objects" can represent abstract concepts,
not just concrete things. -- I think we are straining too hard here to
have a so-called "pure" terminology and we will end up shooting
ourselves in the foot. Having to explain a choice over and over is an
indicator that we may have created an unnecessary hindrance to
acceptance and understanding.
Daniel
>>> Nataraj Nagaratnam <natarajn@xxxxxxxxxx> 2/21/2008 9:48 PM >>>
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/Austin/IB
M@IBMUS
To
Sent by: "Higgins \(Trust Framework\)
higgins-dev-bounc Project developer discussions"
es@xxxxxxxxxxx <higgins-dev@xxxxxxxxxxx>
cc
"'Higgins \(Trust Framework\)
02/21/2008 09:34 Project developer discussions'"
PM <higgins-dev@xxxxxxxxxxx>,
higgins-dev-bounces@xxxxxxxxxxx
Subject
Please respond to RE: [higgins-dev] Data Model
(yet
"Higgins \(Trust again)
Framework\)
Project developer
discussions"
<higgins-dev@ecli
pse.org>
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."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
