I think perhaps in my mind, Kind (or What an item IS) is not an intrinsic attribute of an Information Item? Maybe that's what you mean when you say that Stamping simply adds a new set of intrinsic attributes? e.g. Date sent is added when an Item becomes a Communications Item.
Below are the attributes that 1. I think are intrinsic to an Information Item; and 2. I can't really see why different people sharing the same Item would want to annotate/maintain independent, private values for each attribute. + Created by + Edited by, Edited on + Last Edited by, Last Edited on + Sent/Received/Updated on + Last Sent/Received/Updated on As for all other attributes, even if they are intrinsic to an Item (e.g. Start time, Timezone, Alarm, Hair color, Company, Due date), you can imagine that different sharees might want to maintain personalized values for these attributes. Caveat: I don't think we need to solve all of these problems in 0.7 or even 1.0. My worry is, if we allow users to define their own attributes...we run into a conceptual inconsistency if we allow them to pick and choose which user-defined attributes are in/out of the sharing cloud, but we don't allow them to pick and choose which out of the box attributes are in/out of the sharing cloud. e.g. I can define an attribute: Task type: To read and choose to make that private, but I can't Stamp an item as a Task and choose to keep that private. But maybe that's okay and is actually the best way to dis-ambiguate read-only attributes that the user can't change from user-defined attributes the user can add to a read-only Item. I will explore this issue a bit more on my own and come up with a few design propols as to how we can make clear which attributes are shared/not shared. This has also been requested as a part of the dogfood feedback. Thx Mimi On 4/18/06, Katie Capps Parlante <[EMAIL PROTECTED]> wrote: > Mimi Yin wrote: > > Are you saying, intrinsic versus not intrinsic-ness of an attribute = > > needs to maintain integrity wrt r/w-ness versus doesn't need to maintain > > integrity wrt r/wness? > > No, I can see that one might want to add some "intrinsic" attribute > annotations to a read-only item: notes or tags or date fields or whatever. > > It might imply a difference in the ui -- it seems like it will be harder > to communicate that some attributes are annotations/editable and others > are read-only. Not insurmountable. > > > I'm not sure if this relationship is necessarily true. Semantically it > > makes sense to me that a mailing list message is a "Task" for me because > > I need to reply to it, but is not necessarily a "Task" for Jeffrey, even > > though we're both subscribed to the same Discussion Collection. Or is > > that what you're trying to say? Because the examples you give in your > > next email seem to be in-line with this example. > > > > Hmmm, I'm feeling like this email has too many recursive pronouns. > > > > *Question *Is Stamping as a Task an intrinsic attribute or a > > non-intrinsic attribute in your view? > > It seems to me that once you've stamped something, it now has new > intrinsic attributes. > > It might not have been a helpful comment -- just noting that > conceptually one could think about the two cases differently. > > Cheers, > Katie > > > On Apr 17, 2006, at 4:36 PM, Katie Capps Parlante wrote: > > > >> Mimi Yin wrote: > >>> I guess conceptually, if we allow users to add read-only items to > >>> different collections, which in turn "label" the items > >>> accordingly...then what is the difference between adding a read-only > >>> item to a ToRead collection in the sidebar versus: > >>> Stamping a read-only item to show up on My Task list. > >> > >> It seems like there is a conceptual difference here -- perhaps its > >> related to what you have called "intrinsic" attributes and whatever it > >> is we call attributes that are not intrinsic. > >> > >> It makes sense that you can put read only items in different kinds of > >> containers, or are able to change relationships between editable items > >> and read only items. That feels different from an end user perspective > >> of having the "intrinsic" item feel like its half editable and half > >> not editable, as in your stamping case above. > >> > >> Cheers, > >> Katie > >> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ > >> > >> Open Source Applications Foundation "Design" mailing list > >> http://lists.osafoundation.org/mailman/listinfo/design > > > > > > > > ------------------------------------------------------------------------ > > > > _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ > > > > Open Source Applications Foundation "Design" mailing list > > http://lists.osafoundation.org/mailman/listinfo/design > > _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ > > Open Source Applications Foundation "Design" mailing list > http://lists.osafoundation.org/mailman/listinfo/design > _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "Design" mailing list http://lists.osafoundation.org/mailman/listinfo/design
