| RE: [higgins-dev] Identity Relationships |
|
Thanks Paul, this helps a lot.
>>> On Sunday, March 12, 2006 at 12:09 am, in message <01ca01c645a3$e7c040c0$6901a8c0@IBMR31>, paul@xxxxxxxxxxxxxxxxx wrote:
Jim Sermercheim wrote:
Another question:
This time referring to the Identity Relationships http://spwiki.editme.com/DigitalIdentity.
First, I was going to ask if this section was only talking in concepts because there isn't any mention of a mechanism used to form any of the Identity Relationships mentioned. I wondered if there was some specific Identity Attribute used to do this (like seeAlso=<some identifier>), but then I saw it mentioned the relationships being maintained somewhere that seems to be outside of the Digital Identities themselves.
I've updated the above wiki page. We do envision two specific kinds of Identity Attributes. For DI-to-DI references within the same Context we call these attributes "Edges". For DI-to-DI references across contexts we call these attributes DIRefs.
The relationships are not maintained anywhere other than being the values of attributes within claims of the DI. I like that a lot better than my previous impression that they were held somewhere separate from the DI's.
So, later I saw http://spwiki.editme.com/Link. I think this must be the mechanism I was missing. If so, the disconnect I see there is that the Link definition doesn't allow a cross-Context relationship. Maybe the definition is just out of date? Or maybe I'm wrong in associating the two to begin with.
Sorry, that Link page is out of date. Links have been replaced by Edges. The Link page has been deleted.
Back to the notion of relationships: Is there the notion of a "type" of relationship?
We've not yet documented Edges on the wiki. In the code Edges are implemented as RDF Properties. This means that arbitrary metadata (including "type" tags) can be added to Edges.
To use the examples on the page, the relationship between the two identities for "Bob Smith" is a kind of "see also" relationship, while the relationships between a group and its members are more like "member" and "member of" (depending on direction).
Yes. The "group" relationship has been suggested, but could be modeled a number of ways. Personally, I'd like to see it implemented using explicit "member" and "member of" references. Others have suggested that a separate GroupDigitalIdentity be created as an explicit container class. This is currently undecided. Without knowing the arguments, I agree with using references over growing the number of classes. Specializing a container class like that may set a precedent leading to others (i.e., to meet the needs of other types of relationships like those listed below (hierarchy, dynamic groups, etc.) Other types might include organizational hierarchy (subordinate/superior), or lineage (like a pedigree chart). Further, more 'dynamic' relationships could temporarily exist, based on current claims of other Identities (for example: assuming Bob Smith has a Digital Identity with a claim like favoriteBand=Radiohead, relationships could be produced (directed edges I guess is the API term) to and from all other Digital Identities with the same claim.
True. The advantage of explicit Edges with arbitrary (even dynamic) type is that it makes modeling these things easy.
Maybe that last example is outside the scope of what Higgins wants to do.
No it's not outside the scope. Higgins has a whole set of use cases that it wishes to support that involve many kinds of binary relations between DIs.
The question is really: can I filter the relationships (edges, I think) of an identity?
This is something that Higgins needs to be able to do. The API is currently not there for this.
Can I ask the question: Is "bsmith" a "member of" the "US Tennis Team" and not get a false-positive because "bsmith" is "subordinate to" the "US Tennis Team" (both being current relationships)?
The objective is to be able to do this kind of thing, yes.
Jim |