@evan @erincandescent @julian @mikedev @silverpill boosting, replying, and grouping are three completely separate functions. the Announce could have its own inReplyTo and/or context.
@evan @erincandescent @julian @mikedev @silverpill boosting, replying, and grouping are three completely separate functions. the Announce could have its own inReplyTo and/or context.
@trwnh @erincandescent @julian @mikedev @silverpill
Maybe we need to agree that these two properties are different.
I agree that `context` is great for a related collection of objects, including for a project or event, as defined in AV.
For the specific collection of objects that are members of the same reply tree, we can use `thread`.
If it doesn't matter to specify that it's a thread, you can link to the exact same collection with `context`. It is, after all, also a related collection.
@trwnh @erincandescent @julian @mikedev @silverpill
Maybe we need to agree that these two properties are different.
I agree that `context` is great for a related collection of objects, including for a project or event, as defined in AV.
For the specific collection of objects that are members of the same reply tree, we can use `thread`.
If it doesn't matter to specify that it's a thread, you can link to the exact same collection with `context`. It is, after all, also a related collection.
@scott yes, this can generally be accomplished by defining vocab terms for each type of collection, representing its purpose or classification -- for example, Context / Conversation / MediaAlbum / CuratedMoment / whatever. these are moreso progressive enhancements, though -- if you follow a link, then the link relation is usually enough information to know where you're going, if not necessarily enough to know what you've arrived at. a category is not always a context; context implies purpose.
@scott yes, this can generally be accomplished by defining vocab terms for each type of collection, representing its purpose or classification -- for example, Context / Conversation / MediaAlbum / CuratedMoment / whatever. these are moreso progressive enhancements, though -- if you follow a link, then the link relation is usually enough information to know where you're going, if not necessarily enough to know what you've arrived at. a category is not always a context; context implies purpose.
@scott for example, a blog post is in one or more categories/tags/taxonomies, but the blog post does not exist purely within any of those groupings. generally if something exists in a context, you are less interested in that thing and more interested in the context in which it exists. the context provides a reason or purpose for that object; you can group all objects that share the same context and end up with some cohesive understanding of something.
@scott for example, a blog post is in one or more categories/tags/taxonomies, but the blog post does not exist purely within any of those groupings. generally if something exists in a context, you are less interested in that thing and more interested in the context in which it exists. the context provides a reason or purpose for that object; you can group all objects that share the same context and end up with some cohesive understanding of something.
@evan @erincandescent @julian @mikedev @silverpill Sure, it's possible to declare both a `context` being whatever grouping, and a `thread` being specifically a reply tree. (Perhaps `thread` should be renamed to `replyTree`, and `root` should be renamed to `replyTreeRoot`?)
I'm specifically against conflating the two concepts, though. I also would prefer to not give `inReplyTo` any undue deference beyond simply being metadata. For as many systems that rely on it, there are systems that don't.
@evan @erincandescent @julian @mikedev @silverpill Sure, it's possible to declare both a `context` being whatever grouping, and a `thread` being specifically a reply tree. (Perhaps `thread` should be renamed to `replyTree`, and `root` should be renamed to `replyTreeRoot`?)
I'm specifically against conflating the two concepts, though. I also would prefer to not give `inReplyTo` any undue deference beyond simply being metadata. For as many systems that rely on it, there are systems that don't.
@evan @erincandescent @julian @mikedev @silverpill For example, replying to a message is something that the user *explicitly chooses* to do when in the context of image boards or chat rooms. If you've ever used Discord, then you can see how in that system, it wouldn't make any sense to say that every message in a channel necessarily must be inReplyTo some other message in the channel (or anything at all). The room is a bound context.
@evan @erincandescent @julian @mikedev @silverpill For example, replying to a message is something that the user *explicitly chooses* to do when in the context of image boards or chat rooms. If you've ever used Discord, then you can see how in that system, it wouldn't make any sense to say that every message in a channel necessarily must be inReplyTo some other message in the channel (or anything at all). The room is a bound context.
@trwnh @erincandescent @julian @mikedev @silverpill sounds great.
I'm going to stick with `thread` and `root`.
They're already namespaced, and these are clear terms for these concepts.
Thanks for the help with additional use cases on forking and grafting. I'm going to add some explicit user stories to the FEP and show how each one can be handled.
@trwnh @erincandescent @julian @mikedev @silverpill sounds great.
I'm going to stick with `thread` and `root`.
They're already namespaced, and these are clear terms for these concepts.
Thanks for the help with additional use cases on forking and grafting. I'm going to add some explicit user stories to the FEP and show how each one can be handled.
@trwnh @erincandescent @julian @mikedev @silverpill yes, I absolutely agree that a chat room is topologically different from a forum thread, a Reddit post, or a social network.
@trwnh @erincandescent @julian @mikedev @silverpill I would represent a chat room as a `Group`.
@trwnh @erincandescent @julian @mikedev @silverpill I would represent a chat room as a `Group`.
@evan @erincandescent @julian @mikedev @silverpill One thing to note: If the AS2 context extension policy ever gets adopted and these terms likewise get adopted into the w3.org/ns/activitystreams context document via that process (or any other process), then this creates an issue for any other case where someone wants to use the plain-JSON keys `thread` and `root`.
@evan @erincandescent @julian @mikedev @silverpill One thing to note: If the AS2 context extension policy ever gets adopted and these terms likewise get adopted into the w3.org/ns/activitystreams context document via that process (or any other process), then this creates an issue for any other case where someone wants to use the plain-JSON keys `thread` and `root`.
@evan @erincandescent @julian @mikedev @silverpill
1) I disagree; chat rooms, forum threads, comments sections, etc. are all just different presentations of the same generic data structure (objects in collections). I could pull the AS2 data for this entire chain of replies and render it as a chat room, or as a messenger, or however I wanted to -- flat chronological list or otherwise.
2) I would use `Group` to represent an actual group of agents. For a group of posts, I would use Collection.