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.
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.
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.