Why no Request in addition to Offer ?

[srosset81]

Type

• [ ] Editorial
• [ ] Question
• [x] Feedback
• [ ] Blocking Issue
• [ ] Non-Blocking Issue

Issue

In the ActivityStreams vocabulary spec, it is written:

The Offers use case deals with activities involving offering one object to another. It can include, for instance, activities such as "Company A is offering a discount on purchase of Product Z to Sally", "Sally is offering to add a File to Folder A", etc.

To open the possibility of using ActivityStreams for classifieds or marketplace-like apps, couldn't we consider adding a Request activity, which would be the other side of Offer ?

Offer can be used in many cases but I feel Request can be more explicit. In the second example above ("Sally is offering to add a File to Folder A"), it is clearly a suggestion. But a Request would be more affirmative, and it would imply that an answer is expected.

Background

We are writing an event management app, where events are private by default and can only be seen by invitees. The organizser can give some invitees the right to invite their own contacts. We use the Offer activity in two cases:

• When the organiser wants to tell an invitee he has the right to invite his own contacts, he sends an activity of type: Offer > Invite > Event
• When an "inviter" (someone with the right to invite) wants the organizer to invite some of his contacts, we also use an activity of type: Offer > Invite > Event.

In the first case, Offer is appropriate because it is a suggestion ("Please invite your friends"). But in the second case, we feel that the Request verb could be more appropriate ("Alright, so you can invite John and Jill").

We also plan to write a classifieds app, where Requests and Offers would be central.

[sebilasse]

Is there a big difference to the Question Activity?

[srosset81]

Well, I think there is ! :-)

The Question activity is designed for polls. It is about choosing one or more answers. https://www.w3.org/TR/activitystreams-vocabulary/#questions

The Request activity would be about asking an actor to do something. Like for example "I ask you to invite my friend to your party" (Request > Invite)

[sebilasse]

Who told you it is designed for polls? It was mastodon who decided to restrict it to polls. In no way we should let mastodon overtake the protocol (please read the spec.).

Represents a question being asked. Question objects are an extension of IntransitiveActivity. That is, the Question object is an Activity, but the direct object is the question itself and therefore it would not contain an object property.

Either of the anyOf and oneOf properties may be used to express possible answers, but a Question object must not have both properties.

What gave you the idea it is a Poll? Saying it very clear: A Question is a Question (otherwise it would be named 'Poll') … It can be a question, request or poll. If you would like to federate with @redaktor or huge European Publishing Houses: A Question is a Question

• used with oneOf is a “Poll”
• used with anyOf is a “Request”
• used open is a “Question”

cc @evanp

[aschrijver]

Yes, a Question could be used for any type of inquiry. The question (no pun intended) is: Should it be used to model e.g. a Request?

(note that the original activitystreams 1.0 had way more activity-types, including request, and they have been deliberately culled in v2.0)

Imho there is a general problem in the AS/AP where everyone tries to map their own domain model to the 'social primitives' that are provided in AS-Core spec. This only works if there is a broad common understanding of the semantic concept and heuristics that are modeled. Where that's not the case, some apps Offer may have completely different meaning than another apps Offer does. Same case where you use Question and an impl that Retrospring might implement later on.

So, again imho, options are:

1. Implement using standard AS, if that is compatible to other common uses of these activities
2. Implement as AS/AP vocabulary extension to make it clear what domain the model refers to.

For 2) it need not be app-specific. There could be standardization on an Event Management domain. Problem with 2) is that proper ways and best-practices to define vocab extensions and for others to reuse them too, is very poorly defined.

[sebilasse]

In the meeting I had proposed a way to solve exactly this because the ActivityStreams inventors (James and Evan) wanted to have a possibility to describe potential resulting actions to others. But it was specified before AP, so today the default ActivityHandler would be an ActivityPub object … The document is far from being ready (and we need to be careful to never publish anything which could have security implications done wrong), so I would be curious what the people from the meetings, e.g. @yuforium thinks of it.

Anyway, the discussion by the time was here: https://www.w3.org/wiki/Activity_Streams/Expanded_Vocabulary#Potential_Actions_attached_to_objects

[srosset81]

What gave you the idea it is a Poll? Saying it very clear: A Question is a Question (otherwise it would be named 'Poll') … It can be a question, request or poll.

IMO in English the difference between a Question or a Request is quite clear. A Request is somewhat directive: "Can you invite me to your event" ? While a question could be: "How many people do you expect at your event ?". Both are indeed questions, but they have different intents.

Additionally, the first one can be simply Accepted, while the second one requires a message.

The examples given here are quite clear: https://www.askdifference.com/question-vs-request/

I agree that the AS ontology is not supposed to handle everything. But since we already have an Offer activity, I wonder why we don't have the "opposite" Request activity. I give again the example used for Offer activities:

The Offers use case deals with activities involving offering one object to another. It can include, for instance, activities such as "Company A is offering a discount on purchase of Product Z to Sally", "Sally is offering to add a File to Folder A", etc.

In a marketplace-type app, Sally could be "offering" objects she doesn't need anymore but she could also be "requesting" objects she needs. I don't see how Question could fit here.

[sebilasse]

Well, just wanted to say that Question is a broader term than Request. German words are "Frage" and "Anfrage" :) Question and Response is IPTC Level 1 – while a Poll is an incredible narrow term (IPTC Level 4 [or 3 as "Polls and Surveys"])

However, some history: Some terms were deprecated in ActivityStreams and AP was specified. Basically in the meantime the AS inventors thought about “Describing Potential Actions and result”. The result property is unfortunately not used by many but both together can give a really redundant/idempotent/good way to federate (don't know exact word). I can show in the next meeting https://socialhub.activitypub.rocks/t/developers-meeting-7-a-standard-way-to-query-in-activitypub/2488 This way we could use it as a Subclass of Question but also describe the exact actions/workflow.

[evanp]

@srosset81 I think you make the case that a Question is a request for information, and a Request would be a request for activity or object.

In either case, if Question doesn't work for your use case (which sounds very cool, and I hope actually happened!), it would make a lot of sense to add a Request activity type.

The best next step for you would be to define a Request activity type extension; you can see some examples of how to do it at https://www.w3.org/wiki/Activity_Streams/Primer/Extensions . If the extension becomes popular, we can add it directly to the Activity Streams 2.0 context; see https://w3c.github.io/activitystreams/draft-extensions-policy.html for roughly how it would happen.

[evanp]

One thing that came up during issue triage is that there isn't a clear symmetry between Offer and Request.

A good use case to consider is stock markets (or other markets). An "ask" is an Offer to sell something at a particular price, and a "bid" is an Offer to buy something at a particular price. Both sides of the transaction map cleanly onto Offer, without the need for a Request.

Care should be taken in defining this extension not to confuse the two too much.

[markcellus]

An "ask" is an Offer to sell something at a particular price, and a "bid" is an Offer to buy something at a particular price.

"ask" in this context seems like Question--not an Offer, unless I'm missing something.

[aschrijver]

Cross-reference: This issue mentioned in FEP-0837: Federated Marketplace by @srosset81 in the context of considering a Valueflows vf:Proposal type.