[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[higgins-dev] Re: higgins-dev Digest, Vol 8, Issue 26
|
Hello All,
I recently joined this group and since there has been a lot of interest regarding JNDI
I thought I would mentioned another mailing list I am part of, namely a JNDI one that exclusively dicusses JNDI issues, here it is
JNDI-INTEREST@xxxxxxxxxxxx
On 3/30/06, higgins-dev-request@xxxxxxxxxxx <higgins-dev-request@xxxxxxxxxxx
> wrote:
Send higgins-dev mailing list submissions to
higgins-dev@xxxxxxxxxxx
To subscribe or unsubscribe via the World Wide Web, visit
https://dev.eclipse.org/mailman/listinfo/higgins-dev
or, via email, send a message with subject or body 'help' to
higgins-dev-request@xxxxxxxxxxx
You can reach the person managing the list at
higgins-dev-owner@xxxxxxxxxxx
When replying, please edit your Subject line so it is more specific
than "Re: Contents of higgins-dev digest..."
Today's Topics:
1. Weekly Higgins-dev development conference call at 5:00 EST
today (Mary Ruddy)
2. RE: attributes vs relationships (was Higgins data model)
(Duane Buss)
----------------------------------------------------------------------
Message: 1
Date: Thu, 30 Mar 2006 14:21:04 -0500
From: "Mary Ruddy" <mary@xxxxxxxxxxxxxxxxx>
Subject: [higgins-dev] Weekly Higgins-dev development conference call
at 5:00 EST today
To: <
higgins-dev@xxxxxxxxxxx>
Message-ID: <046501c6542f$19f68420$020ba8c0@IBMT41>
Content-Type: text/plain; charset="us-ascii"
The dial-in number for our call tonight is:
Date:
Thursday, March 30, 2006
Start Time:
5:00 p.m. Eastern Std Time
End Time:
6:25 p.m. Eastern Std Time
Participants:
10
Type of Conference
Web-Scheduled Standard
Dial-in Number:
1-641-297-5600 (Iowa)
Participant Access Code
762425
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://eclipse.org/pipermail/higgins-dev/attachments/20060330/01a628ed/attachment.html
------------------------------
Message: 2
Date: Thu, 30 Mar 2006 14:35:14 -0700
From: "Duane Buss" <DBuss@xxxxxxxxxx>
Subject: RE: [higgins-dev] attributes vs relationships (was Higgins
data model)
To: <higgins-dev@xxxxxxxxxxx>, <paul@xxxxxxxxxxxxxxxxx>
Message-ID: <
442BECA2.A23D.0025.0@xxxxxxxxxx>
Content-Type: text/plain; charset="us-ascii"
Reply contained only in the top because all the easily readable colors
have been taken.
My assumptions jumping into the middle of this are as follows, if any
of these are incorrect please feel free to flame me.
The Higgins framework plans on consuming identity information from a
wide variety of existing 'identity' data stores, which stores already
have a data model which may or may not be open to change. In an ideal
world we all stores would eventually upgrade to Higgins new and improved
model, but reality is we will have to work with legacy systems composed
of feral identities.
A digital identity may be composed of facets from multiple data stores.
Management of the identity facets may take place through means other
than the Higgins framework.
Higgins references may be within an identity store or cross identity
stores.
We are discussing the data model not the interfaces or class diagrams.
The Higgins data model is intended to facilitate creation of digital
subjects, without limiting the type of feral data stores from which
attributes are retrieved.
Attributes vs Relationships
Many of the existing identity data stores from my first assumption
support references within the data store, often as an attributes. In
Jim's examples below objects refer to each other via attributes which
contain an object identifier. In an SQL data base any field (aka
attribute) may be used to join tables, resulting in object references
via an attribute value. Am I correct in assuming that the Context
Provider would be required to represent those attributes as
relationships rather than as attributes?
Depending on the store these attributes which are references links
may not allow for concepts like properties on the link. If an
application built on top of the Higgins framework were to attempt to add
properties to the link I can see at least two implementation options.
First the Context provider could deny the operation, second the Context
Provider could have a data store for additional relationship
properties. (Please don't rathole on the referential nightmare.)
This brings up the issue of where Higgins data is actually stored. And
while a glib 'where ever the context provider wants to store it' might
allow us to proceed to other data model issues, it is a significant
implementation detail. In the example above the link existed as a
attribute, what if no link existed and it was being created by
application. The context provider could:
Store the link as an attribute within the identity store, and live with
any limitations that brings
Store the link as a new object or reference to an entry in a table
within the identity store. Since the identity store may be maintained
using management tools which know nothing about Higgins notion of
relationships (assumption #3) , these extra bits of data might be
orphaned, tampered with or otherwise mismanaged by an unaware
user/application.
Store the link information in some separate data store. This last
option is the most flexible, but involves overhead maintaining the
additional store, joining results, and dealing with referential
integrity.
This problem is compounded when instead of linking facets within a
single identity store we are composing a digital subject from a multiple
identity stores. Do both identity stores get links? Or do we store
link information somewhere else?
As a procedural side note I would like to see the end results of some
of these discussions summed up on the wiki (with references to the
mailing list archives).
Duane
>>>
From: "Paul Trevithick" <
paul@xxxxxxxxxxxxxxxxx>
To:<higgins-dev@xxxxxxxxxxx>
Date: 3/29/2006 2:52:47 pm
Subject: RE: [higgins-dev] attributes vs relationships (was Higgins
data model)
Replies in green.
-----Original Message-----
From: higgins-dev-bounces@xxxxxxxxxxx
[mailto:higgins-dev-bounces@xxxxxxxxxxx
] On Behalf Of Jim Sermersheim
Sent: Wednesday, March 29, 200612:51 PM
To: higgins-dev@xxxxxxxxxxx
Subject: RE: [higgins-dev] attributes vs relationships (was Higgins
data model)
Replies in red
>>> On Wednesday, March 29, 2006at 9:23:23 am, in message
<01e601c6534d$19bb4b90$9601a8c0@VGCRB30>, "Paul Trevithick"
<
paul@xxxxxxxxxxxxxxxxx> wrote:
Hi Jim,
You present a scenario where Case 2 wins. But I think that was an
unusual scenario. I think that the attribute/relationship distinction is
clear and obvious most of the time. Do you disagree?
I'm not sure. I do know that in the world of directories, all
relationships but one (hierarchy) are modeled via attributes and that
even the built in Hierarchy mechanism only adds confusion (could
have/should have been done with attributes). That's not to say I want
the model to behave just like a directory, just anecdotal evidence.
FWIW, I wasn't trying hard to contrive that example, it's more that I
have the feeling that this kind of thing will come up over and over
where people will start out using attributes for something, and later
find they need to switch over to using relationships in order to
minimize data duplication.
Actually, thinking about it more, I think the example is pretty common.
At livejournal.com
(and I imagine other blog sites as well), one can
list their interests. If an interest is shared by another user, or if
there's a community for that interest, then a relationship (link) is
formed. If not, the interest is only simple text. How is it stored in
the back-end? I dunno for sure, but I suspect not as two quite different
sets of data.
I need to think about this some more.
On a somewhat related matter.
Your use of the word type (as in type = "string") is interpreted by me
to mean "the type of this attribute's value". Yet I would have expected
that the value of an attribute was an object whose type was discoverable
through reflection. In other words I would have expected you to write
your examples like this:
{name = "interest", "B-Movies"}
where "B-Movies" was a String object. Is this an implementation-related
issue, is this just common practice in directory work. Or am I just
missing something entirely?
Not being sure how attributes are going to be typed in the higgins
model, I only did that as a means of clarification.
I see.
With directories, each named attribute has a separate schema definition
which dictates its form. One has to use the attribute identifier to go
look up the schema definition to discover the type/form (or just have
a-priori knowledge of that attribute's type/form).
Seems reasonable.
If higgins proposes to use reflection, we better make sure that the
target programming languages support it (do we have a list of target
programming languages yet?).
I should have said "discoverable through reflection or lookup of some
kind". I was just trying to understand if you thought that there really
would be a "type = "String"" property or not. You answered my question.
There is no need for this in the model.
As for a list of target programming languages. We don't have one but
it's probably true that assuming reflection is available is a bad idea.
(Further, I'm hoping that "interest" is really a URI like
"
http://foo/bar/baz/interest")
Yeah, that's the problem with writing quick examples, I let side
details slide. I think everyone would agree that Attribute identifiers
need to be unique (and a URI is one good way to do that).
-Paul
So, I'm not sure where we are with this. If we stick with Case 1, we
can decide to ignore it, or we can state that all values of an attribute
must be of the same type, and if that type has a need to (always or
sometimes) link to another facet, it really should be a relationship.
Here's what I see as the rub in Case 1. As long as there's a way to
"point at" another facet (using it's identifier for example), then
there's nothing to stop anyone from coming up with an attribute (complex
or simple) which has as a field, a facet pointer. Once that practice is
established, it will be confusing to know when to do that versus using
relationship objects.
Yes, as I said above, I need to mull this all over a bit.
What prevents this kind of confusion in the graph-world?
Well let me pick one "graph-world". In the RDF world you don't have
this confusion cuz everything is, in a sense, a relationship. E.g. {Tom
isInterestedIn B-Movies}. "isInterestedIn" is the property (predicate),
"Tom" is the subject, and "B-Movies" is the object. If two people are
interested in B-Movies, the B-Movies object (technically a "resource")
can be shared. And since "isInterestedIn" can act as a subject, you can
even attach a Property to it: {isInterestedIn degreeOfInterest
"obsessive"}.
Jim
-----Original Message-----
From: higgins-dev-bounces@xxxxxxxxxxx
[mailto:higgins-dev-bounces@xxxxxxxxxxx
] On Behalf Of Jim Sermersheim
Sent: Wednesday, March 29, 20062:32 AM
To: higgins-dev@xxxxxxxxxxx
Subject: Re: [higgins-dev] attributes vs relationships (was Higgins
data model)
After reading this, I dislike the word "like" as used. replace it with
"interest" and it reads better (purely aesthetic).
>>> On Tuesday, March 28, 2006at 6:46:53 pm, in message
<4429849D.D091.001C.0@xxxxxxxxxx>, "Jim Sermersheim" <jimse@xxxxxxxxxx>
wrote:
One example that I have a hard time making fit into what I previously
called "Case 1" is where an attribute is sometimes a link to another
facet and other times not.
Say I want to represent my likes. I see this as an attribute. For
example, I could list:
{name = "like", type = "string", stringVal = "B-Movies"}
{name = "like", type = "string", stringVal = "Skiing"}
{name = "like", type = "radioStation", callLetters = "KRCL", band =
"FM", frequency = "90.9", preferredDJs = {name = "The Old Man", name =
"Robert Nelson"}}
But hold on, I happen to note that there already exists another facet
in my context which represents KRCL (the radio station). Rather than
typing all that garbage into the attribute on my facet, I'd prefer to
link to it. Of course, *only* linking to it causes me to lose my
"preferredDJs" list. So now I want to associate a property with the
link. Both Case 1 and Case 2 allow for this. The difference as I see it
is that Case 1 now causes my list of likes to be spread across my
attributes and relationships. The modified Case 2 follows:
Jim {
Attributes {
{name = "like", type = "string", stringVal = "B-Movies"}
{name = "like", type = "string", stringVal = "Skiing"}
{name = "like", type = "radioStationRelationship", relatedTo =
"xyz://myContext/KRCL", preferredDJs = {name = "The Old Man", name =
"Robert Nelson"}}
...
}
}
Case 1 looks something like:
Jim {
Attributes {
{name = "like", type = "string", stringVal = "B-Movies"}
{name = "like", type = "string", stringVal = "Skiing"}
...
}
Relationships {
{type = "like", from = "xyz://myContext/Jim", to =
"xyz://MyContext/KRCL", toType = "radioStation", preferredDJs = {name =
"The Old Man", name = "Robert Nelson"}}
...
}
}
The interrogator of my likes in Case 2 enumerates the "like" attribute
types, discovers their types, and processes. In processing a
"relationship" type, it must dereference the target facet and add the
appropriate properties.
The interrogator of my likes in Case 1 enumerates the "like" attribute
types, discovers their types, and processes. Then enumerates the "like"
relationship types, and for each, dereference the target facet,
discovers its type, processes data from that facet, and adds the target
facet's properties to those on the link.
Note that I added toType to the relationship. This was to avoid having
to dereference the target facet in order to know what properties to
expect on the relationship object. Similarly, I used type =
"radioStationRelationship" in Case 2. Both cases can be simplified (type
= "relationship" in Case 2, and remove the toType in Case 1), but that
causes the interrogator to dereference the target and read it's type to
know what to expect in terms of further properties.
If the group prefers Case 1 over Case 2, how can we make this example
less awkward? I don't really like going the other possible direction to
fix it (make facets for B-Movies and Skiing, and any other potential
"like" out there).
Jim
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://eclipse.org/pipermail/higgins-dev/attachments/20060330/8f1d9fc7/attachment.html
------------------------------
_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev
End of higgins-dev Digest, Vol 8, Issue 26
******************************************
--
Regards
Amitpal Dhillon
