Post by @smallcircles@social.coop

To just name a well-known existing eCommerce vocabulary: GoodRelations.

http://wiki.goodrelations-vocabulary.org/Cookbook/

Not saying it is appropriate, or the only choice, but just as example. Here you'd have a gr:Offering instead of an as:Offer to indicate "something available for purchase (or bartering)". And there are a bunch of constructs to model payment, delivery methods, etc.

Avoiding the very generic as:Offer has the advantage you convey proper meaning, and don't get to deal with "whack-a-mole" development where you have to adapt your internal business logic to all the overloaded uses some app developer put on the fediverse wire for their own custom as:Offer interpretation :)

Cookbook/index

3 Replies

0 Boosts

ivan

@ivan 5 months ago

@smallcircles@social.coop @box464@mastodon.social oh super interesting!

ivan

@ivan 5 months ago

@box464@mastodon.social @smallcircles@social.coop @bhaugen@social.coop @lynnfoster@social.coop

🪨

@Varpie@peculiar.florist 5 months ago

@box464@mastodon.social I think the Announce isn't really needed in the first place, the original Create should allow the object to reach its audience. Also, Offer is an activity, so the first one feels odd. I'd just Create a Note with the details, or some custom object if you want to have it used as a special logic for the frontend, or want to use custom fields for price for instance. Maybe using schema.org's Product (I just find the fact that they use their own Offer type for the price a bit confusing)

🫧 socialcoding..

@smallcircles@social.coop 5 months ago

@Varpie @box464 @ivan

Yes. Depending on what you want I'd follow a more design-first approach of the particular domain you want to model. And not shy away from custom types, or better, an existing domain-specific vocab.

On the fediverse there's this urge to try to cram and map any functionality on the poor #ActivityStreams vocabulary, which only has a small number of 'social networking primitives' to work with. The use case section in the spec at par. 5.8.12 states that Offer involves "offering one object to another" which is a very low-level technical ability, more indicating of a protocol capability than for general use as "business domain".

https://www.w3.org/TR/activitystreams-vocabulary/#motivations

In your last scenario "Bidding" seems to indicate the business domain / bounded context, part of perhaps a larger eCommerce toplevel domain. You might use https://eventmodeling.org

Also: who is the actor? You may have an Offer service, and "OfferService announces Alice's offer".

Interesting too: https://offerbots.org/the-problem/

https://offerbots.org

The Problem

🫧 socialcoding..

@smallcircles@social.coop 5 months ago

@Varpie @box464 @ivan

Btw, I added #OfferBots at the end, a (halted) project by Andrew Mackie, that has a very interesting concept for the #ActivityPub fedi. The website describes *very well* the problem with "aggregators" to be addressed, but the solution section of the website is not up to par. It was stopped right at the time when Andrew became aware of the fediverse.

Discussed here on #SocialHub:

https://socialhub.activitypub.rocks/t/offers-unchained-federated-offerbots/697

🫧 socialcoding..

@smallcircles@social.coop 5 months ago

@Varpie @box464 @ivan

To just name a well-known existing eCommerce vocabulary: GoodRelations.

http://wiki.goodrelations-vocabulary.org/Cookbook/

Cookbook/index

2 more replies