Consider redefining `Invite` to NOT extend from `Offer`

[trwnh]

Please Indicate One:

• Editorial
• Question
• Feedback
• Blocking Issue
• Non-Blocking Issue

Please Describe the Issue:

Offer is described as such:

Indicates that the actor is offering the object. If specified, the target indicates the entity to which the object is being offered.

In plain English, you can translate this to "actor Offered object to target" or "actor Offered object"

Invite is described as such:

A specialization of Offer in which the actor is extending an invitation for the object to the target.

However, this violates the grammatical constructs of object and target as they are used in every other Activity. The plain English formulation ought to be "actor Invited object to target", but it is instead formulated as "actor Invited target to object", which is contradicting what "to" means. As far as I'm aware, Invite is the ONLY activity which is inverted like this.

It might make sense to consider un-inverting the Invite activity so that it works in the exact same way as every other activity. There's no conceptual or technical reason that Invite should inherit or extend from Offer, just a lot of weirdness.

[evanp]

I think this is an interesting topic. First, I agree that the language is incorrect. I also don't think there's a tonne of value in the inheritance structure of these particular activities.

That said, this would be a non-backwards-compatible change; that would require a non-backwards-compatible change to the spec. I wouldn't say it's impossible, but wow, what a lot of trouble for making something work better in English.

[trwnh]

It's more than just working better in English. It has to do with parsing the semantics of any given activity. Right now, Invite has to be special-cased as an exception, so that when you see `object` on an Invite, you have to be somehow aware that it is NOT the actual object of the activity. Generic activity handling suffers as a result, as does any semantic processing.

…

On Fri, Oct 11, 2024, 11:09 Evan Prodromou ***@***.***> wrote: I think this is an interesting topic. First, I agree that the language is incorrect. I also don't think there's a tonne of value in the inheritance structure of these particular activities. That said, this would be a non-backwards-compatible change; that would require a non-backwards-compatible change to the spec. I wouldn't say it's impossible, but wow, what a lot of trouble for making something work better in English. — Reply to this email directly, view it on GitHub <#619 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACQ5OXZ5TCQNUNRAUQR27J3Z27Z35AVCNFSM6AAAAABPYFLE7SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMBXG4ZDANZRG4> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[evanp]

I think the problem with any redefinition of Invite is that it's not backwards compatible. Any existing software that uses this definition would be looking in the wrong place for the invitee and the thing they are invited to. We think (in issue triage) that this is a small number of implementations, but just in the principle of backwards compatibility, it would be a problem.

One possibility here is to define an extension that defines an activity where the person being invited is the object and the thing they're being invited to is the target. The problem here is that the very natural term Invite has already been used, so you'd need to find a good synonym, or deal with namespacing, which would be a problem as you head towards including the extension in the default context document.

So, again, three outcomes:

1. Deal with it.
2. Change it, but non-backwards-compatible.
3. Create an extension.

[github-actions]

This issue has been labelled as potentially needing a FEP, and contributors are welcome to submit a FEP on the topic.
Note that issues may be closed without the FEP being created; that does not mean that the FEP is no longer needed.

[bumblefudge]

Discussed on today's Triage call, I think making the Invitation an OBJECT (that uses the offer verb instead of varying it) makes more sense.

[bumblefudge]

@bobwyman points out that "Invitation" sounds like an Authorization (implies rights, authentication of a token, etc), which feels to me like a good argument for next-version AP/AS including Invitation in objects and removing Invite as a verb

[bobwyman]

@bobwyman points out that "Invitation" sounds like an Authorization (implies rights, authentication of a token, etc), which feels to me like a good argument for next-version AP/AS including Invitation in objects and removing Invite as a verb

Yes. An "invitation" is different from a mere announcement of an event. One may announce an event even to those who are not permitted to attend. (For instance, the President might announce a meeting with some foreign leader.) Those who are "invited to an event" are "offered an invitation to the event." That invitation grants them a right to attend, not merely to know that the event is happening. In the old, pre-online world, one would carry a paper invitation as a proof of the right to attend the event. My expectation is that we must eventually include an RLE (Rights Expression Language) in Activity*. Once that is done, I expect that an invitation object would often include some description of the specific rights granted by the invitation.

It is also important to understand that an invitation, like other offers, can be accepted, declined, ignored, etc. It is even often appropriate to reply to the offer of an invitation with a counter-offer. For instance, if you offer to me an invitation to "Have coffee on Monday," I may counter-offer with an invitation to "Have coffee on Tuesday." (Note: "Offer" is currently under-specified in Activity*. However, we should anticipate that in some future decade it will, in fact, be more fully elaborated.)

The point here is that the semantics of invitations are very much those of offers. We should avoid making arbitrary distinctions between things that are essentially the same.