Re: [Standards] Labeling Roster Items
On Tue, Apr 1, 2008 at 3:59 PM, Peter Saint-Andre <[EMAIL PROTECTED]> wrote: > Michal 'vorner' Vaner wrote: > > Hello > > > > On Sun, Mar 30, 2008 at 08:53:54PM -0700, anders conbere wrote: > >> On Sun, Mar 30, 2008 at 8:13 PM, Justin Karneges > >> <[EMAIL PROTECTED]> wrote: > >>> On Sunday 30 March 2008 7:34 pm, anders conbere wrote: > >>> > However in XMPP our roster grouping are still relegated to binning or > >>> > boxing (an item in a group exists in one and only one group). > >>> > >>> Actually, in XMPP a contact may be in multiple groups. In fact, the > grouping > >>> is more like "tagging" than any sort of binning, since there is no group > >>> hierarchy stored in the roster (a group cannot exist without a contact > in it, > >>> much like a "tag" can often not exist without at least one thing > tagged). > >> Hmm so this problem is by and large in how Groups are implemented in the > wild? > >> > >> That in and of itself might seem to be reason at least to create a new > >> semantic grouping. Right now I'm struggling to find an number of > >> clients that let me keep users in multiple groups, or at least give > >> me ui to group in a tagging like behavior. > > > > Most clients show them in multiple groups, if they are already in the > > roster. However, many of them have just switch, in which group a contact > > is. > > Right. If your client doesn't do that, use a better client or file a bug > report. :) Yep, sounds like this is purely an implementation issue :) ~ Anders > > Peter > > -- > Peter Saint-Andre > https://stpeter.im/ > >
Re: [Standards] Labeling Roster Items
Michal 'vorner' Vaner wrote: > Hello > > On Sun, Mar 30, 2008 at 08:53:54PM -0700, anders conbere wrote: >> On Sun, Mar 30, 2008 at 8:13 PM, Justin Karneges >> <[EMAIL PROTECTED]> wrote: >>> On Sunday 30 March 2008 7:34 pm, anders conbere wrote: >>> > However in XMPP our roster grouping are still relegated to binning or >>> > boxing (an item in a group exists in one and only one group). >>> >>> Actually, in XMPP a contact may be in multiple groups. In fact, the >>> grouping >>> is more like "tagging" than any sort of binning, since there is no group >>> hierarchy stored in the roster (a group cannot exist without a contact in >>> it, >>> much like a "tag" can often not exist without at least one thing tagged). >> Hmm so this problem is by and large in how Groups are implemented in the >> wild? >> >> That in and of itself might seem to be reason at least to create a new >> semantic grouping. Right now I'm struggling to find an number of >> clients that let me keep users in multiple groups, or at least give >> me ui to group in a tagging like behavior. > > Most clients show them in multiple groups, if they are already in the > roster. However, many of them have just switch, in which group a contact > is. Right. If your client doesn't do that, use a better client or file a bug report. :) Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] Labeling Roster Items
Hello On Sun, Mar 30, 2008 at 08:53:54PM -0700, anders conbere wrote: > On Sun, Mar 30, 2008 at 8:13 PM, Justin Karneges > <[EMAIL PROTECTED]> wrote: > > On Sunday 30 March 2008 7:34 pm, anders conbere wrote: > > > However in XMPP our roster grouping are still relegated to binning or > > > boxing (an item in a group exists in one and only one group). > > > > Actually, in XMPP a contact may be in multiple groups. In fact, the > > grouping > > is more like "tagging" than any sort of binning, since there is no group > > hierarchy stored in the roster (a group cannot exist without a contact in > > it, > > much like a "tag" can often not exist without at least one thing tagged). > > Hmm so this problem is by and large in how Groups are implemented in the wild? > > That in and of itself might seem to be reason at least to create a new > semantic grouping. Right now I'm struggling to find an number of > clients that let me keep users in multiple groups, or at least give > me ui to group in a tagging like behavior. Most clients show them in multiple groups, if they are already in the roster. However, many of them have just switch, in which group a contact is. Gajim (for example) has UI allowing you to put contact in many groups. -- I've already told you more than I know. Michal 'vorner' Vaner pgpzPFoRh2jtG.pgp Description: PGP signature
Re: [Standards] Labeling Roster Items
Dnia 2008-03-30, nie o godzinie 20:53 -0700, anders conbere pisze: > Right now I'm struggling to find an number of > clients that let me keep users in multiple groups, or at least give > me ui to group in a tagging like behavior. Gajim does support contacts in multiple groups for the very long time now. And it's group assigning interface works just like tagging interfaces seen in the wild. > That in and of itself might seem to be reason at least to create a new > semantic grouping. -1 The fact that that our roster "tags" are called "group" does not justify creating yet another standard. This is a client interface implementation issue. -- /\_./o__ Tomasz Sterna (/^/(_^^' http://www.xiaoka.com/ ._.(_.)_ im:[EMAIL PROTECTED]
Re: [Standards] Labeling Roster Items
On Sun, Mar 30, 2008 at 8:13 PM, Justin Karneges <[EMAIL PROTECTED]> wrote: > On Sunday 30 March 2008 7:34 pm, anders conbere wrote: > > However in XMPP our roster grouping are still relegated to binning or > > boxing (an item in a group exists in one and only one group). > > Actually, in XMPP a contact may be in multiple groups. In fact, the grouping > is more like "tagging" than any sort of binning, since there is no group > hierarchy stored in the roster (a group cannot exist without a contact in it, > much like a "tag" can often not exist without at least one thing tagged). Hmm so this problem is by and large in how Groups are implemented in the wild? That in and of itself might seem to be reason at least to create a new semantic grouping. Right now I'm struggling to find an number of clients that let me keep users in multiple groups, or at least give me ui to group in a tagging like behavior. ~ Anders > > -Justin >
Re: [Standards] Labeling Roster Items
On Sunday 30 March 2008 7:34 pm, anders conbere wrote: > However in XMPP our roster grouping are still relegated to binning or > boxing (an item in a group exists in one and only one group). Actually, in XMPP a contact may be in multiple groups. In fact, the grouping is more like "tagging" than any sort of binning, since there is no group hierarchy stored in the roster (a group cannot exist without a contact in it, much like a "tag" can often not exist without at least one thing tagged). -Justin
[Standards] Labeling Roster Items
I think that we've seen some fairly convincing examples of how labeling or tagging can reduce the complexity of grouping sets of data, in particular when it might be difficult to assign the data items into only on individual group. Some big uses of tagging as the primary form of grouping includes gmail, delicious, and flickr. However in XMPP our roster grouping are still relegated to binning or boxing (an item in a group exists in one and only one group). But roster items aren't simple data types, they represent our relationships with people! and people often don't belong to just one group. Rather the people in our lives often belong to many different intersecting groups (my good friend caleb, is both part of the programmers in my life, and my close friends, and my child hood friends, and the people I play soccer with, and climbing). There doesn't seem to be an technical limitation in creating tags or labels for XMPP roster items, there are some questions to be answered about how to store the relations, and what semantics to use when querying them, but these aren't insurmountable. as an initial reference for XEP's that look / act similar there is * MetaContacts - http://www.xmpp.org/extensions/xep-0209.html * Annotations - http://www.xmpp.org/extensions/xep-0145.html My only worry is that both of these use the Storage protocol, and I question how easy it would be to form queries like 'retrieve me all the users with tags "X" and "Y"' Which might be out of band for this XEP but I suspect that queries like that might be powerful.
