Speaking of JNDI, I just got word from Vincent today that he's just returned being away and thinks it'll take a day or so to process the message I sent.
Jim
>>> amitpal.dhillon@xxxxxxxxx 4/2/06 7:51:25 pm >>> 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
|