Offer should be Object, not Activity


#1

@_cj thanks for your response to my question about Updating an Offer

This is a followup. We have been thinking that AP has too many Activities that should be Objects. Offer is one. For economic networks, we will need to extend the ActivityStreams vocabulary, and think that we should do it with new objects, but not new Activities. And some existing Activities that should be Objects are confusing.

It’s like the spec authors tippy-toed into domains that they could have left for other projects that need to go deeper into those domains (to actually do something there) to create new Objects as extensions.

In an economic network, Offer is a type of Intent, which also includes Requests and Proposals. And the Intents will have different properties beyond just “name”.

Join is another one. Actors in economic networks will have lots of different kinds of relationships beyond “joining”, and the relationships will have different names, not just membership. So we would Create Relationships as objects with some properties of their own.

We also think that it will be easier for existing implementations to ignore or do something generic with objects they do not understand than to deal with combinations of new activities and new objects.

So we would say “Create an Offer” or “Create a Relationship”. Each of those would require Acceptance.

Does this make sense to you? What do you think? This connects to your ongoing thoughts about how to cooperatively manage AP extensions.


Updating an Offer
#2

ActivityPub is open-world, in the same way RDF is, so you can freely add properties and make extensions.

I’m worried that if everything that can be an object becomes an object, we’ll end up with 99% of the activities being Create. Because every object that is digital, whose canonical existence is digital, you can model with a Create. There are things like Drink, Eat, Watch etc. which document physical-world activities, but everything else is created when it’s posted.

In ForgeFed I have a use case where you create an object without publishing it on your server. Instead, you offer it to some actor, possibly on another server, and they decide whether to accept it, and host it on their server. Create usually means to create locally (I haven’t verified in the spec that it has to be that way though, I assume there’s a good chance there’s no such thing as “locally” in the AP spec because there’s no “hosting” either), and one of my candidates for implementing create-but-not-publish-locally is to use an Offer activity instead.

I guess it’s a difficult job, just like when authoring any ontology, to decide how to model concept from our mind, our human language and thinking, into the digital information schema. There are so many ways to model things. The ActivityPub spec doesn’t explain why things are the way they are, I wonder if it could be a nice thing to have discussions and decisions and considerations attached to each definition, and it would help evolve the vocabulary.


#3

For economic networks, we will need to extend the ActivityStreams vocabulary, and think that we should do it with new objects, but not new Activities.

That sounds reasonable to me: I understand it’s a delicate balance of re-using as much of what already exists without generating a conflicting interpretation with the existing Activity definitions. If an extension can re-use existing Activities, it also lowers the barrier for adoption.

In an economic network, Offer is a type of Intent, which also includes Requests and Proposals. And the Intents will have different properties beyond just “name”.

If I am reading between the lines, it sounds like a new Offer type (that directly extends from Intent, which itself extends from the Object type) will be designed? That brings an interesting question: How best to model “to offer (verb)” versus “the offer (noun)”. If two types, the former inherits from Activity, the latter would not. If a single type, it would be context-dependent and therefore more up-for-misinterpretation.

It certainly doesn’t help that the ambiguity of the English language can handicap thinking here, since sometimes the word for the verb and noun are the same. So I would be inclined towards two separate types since the “noun vs verb” distinction may be a bigger distinction in other cultures. So if I’m reading between the lines right, it sounds like you’re on a solid path.

As an aside: There’s also a schema.org Offer type.

Join is another one. Actors in economic networks will have lots of different kinds of relationships beyond “joining”, and the relationships will have different names, not just membership. So we would Create Relationships as objects with some properties of their own.

I think this begins to touch on @fr33domlover’s point:

I’m worried that if everything that can be an object becomes an object, we’ll end up with 99% of the activities being Create .

If all the actions an actor can do is viewed in a CRUD-like lens, then I suspect only the Create, Update, and Delete activities will tend to be re-used, heavily. And the question then becomes how applications handle the new data payloads.

I think this paradigm is fine if and only if there’s no additional special caveat side effects for the CRUD activities beyond what is listed in 7.2, 7.3, & 7.4 (and similarly for the C2S sections as well). If an extension wants to say "Create this object and then do these 10 side effects…" then I suspect a new Activity entirely should be used instead. This lets applications keep their Create handling code relatively simple without having a laundry-list of special side effects for all side-effects.

The other consideration is whether to view state as a property or state as the result of actions. The former is way more popular (even within the ActivityPub spec): getting an Activity modifies some state: getting an Accept{Follow} adds an actor to the following collection. To then determine whether I am following someone, I search the state (following collection). On the other hand, modeling state as the result of actions I would search my activities received from an actor and see if the latest was an Accept{Follow} or Reject{Follow} or nonexistant.

The reason this consideration matters is because following the mentality of state as the result of actions results in the demand for more expressive Activities. It also has certain auditing characteristics (to change state requires recording an Activity). As opposed to state as a property which could have been changed on a server without needing an Activity. I don’t know if this matters though.

Thanks for reading my ramblings, hopefully they make sense.